Hi everyone!
The fix didn't bring enough attention back in February for some reason.
So, I'd like to re-request a review.
I've added a regression test, which reliably reproduces a deadlock on my
local Windows 7 machine.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/
Sincerely yours,
Ivan
On 17.02.2015 9:54, Ivan Gerasimov wrote:
Can someone help review this fix please?
Comments/suggestions are welcome!
Sincerely yours,
Ivan
On 06.02.2015 20:48, Ivan Gerasimov wrote:
Hello!
There has been a deadlock in jdk-net code noticed on Windows.
In the bug description there's a stack snippet showing that one of
the deadlocked threads stuck in the native initialization code of
DualStackPlainDatagramSocketImpl and the other -- in initializing of
TwoStacksPlainDatagramSocketImpl.
I suspect that the reason might be due to unordered initialization:
AbstractPlainDatagramSocketImpl, the parent of both classes above,
explicitly loads TwoStacksPlainDatagramSocketImpl from the native
init().
Thus, when both classes are being initialized concurrently, it may
end with a clash.
Another issue noticed by Mark Sheppard is that the Windows version of
DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't
synchronized, but reads/modifies shared data.
Thus, I removed modification and declared all the accessed fields final.
Would you please help review the proposed fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/
The build went fine on all the platforms, all the tests from
(net|nio|io) passed Okay.
Sincerely yours,
Ivan
