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

Reply via email to