On Fri, 4 Jun 2021 02:04:29 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> 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? > > Sergey Bylokhov has updated the pull request incrementally with one > additional commit since the last revision: > > Update SetPositionHang.java Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4141