In the fix for JDK-8207150 I have updated the synchronization of some code
paths under one "lock", before that code was synchronized only on some threads
and missing on others. Old review:
http://mail.openjdk.java.net/pipermail/sound-dev/2018-August/000650.html
That fix introduced this order of locks: "lock"->"synchronized(this)", I have
checked other places and did not found where we use the opposite order.
Unfortunately, one such place exists in the private subclass DirectClip.
I have checked both usages of synchronized which caused deadlock:
- In the DirectClip class the method setMicrosecondPosition is marked as
"synchronized" but it is unclear why. This method is implemented as a call to
another public method setFramePosition which is not "synchronized" and use some
internal synchronization. So I have removed this keyword.
- In a few places we have the code like this:
boolean sendEvents = false;
synchronized (this) {
if (this.started != started) {
this.started = started;
sendEvents = true;
}
}
if (sendEvents) {.....
I doubt that this type of synchronization may help something - the fields are
volatile and we use sendEvents flag after synchronisation block, so I removed
it as well. Any thoughts?
-------------
Commit messages:
- Initial fix
- Update SetPositionHang.java
- Create SetPositionHang.java
Changes: https://git.openjdk.java.net/jdk/pull/4141/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4141&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8266421
Stats: 128 lines in 4 files changed: 106 ins; 11 del; 11 mod
Patch: https://git.openjdk.java.net/jdk/pull/4141.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/4141/head:pull/4141
PR: https://git.openjdk.java.net/jdk/pull/4141
