<Sound Dev> [9] Review Request: 8156169 Some sound tests rarely hangs because of incorrect synchronization

[Phil Race]

+1

-phil.

On 05/18/2016 09:49 AM, Sergey Bylokhov wrote:
> On 17.05.16 19:15, Phil Race wrote:
>> The reason for the change to tracks.toArray() was not obvious
>> from the code and I understood it only after reading your comment
>> below. So perhaps you could add a short comment before you push.
>
> The comment is added:
> http://cr.openjdk.java.net/~serb/8156169/webrev.02/
>
>>
>> -phil.
>>
>> On 05/17/2016 07:30 AM, Sergey Bylokhov wrote:
>>> Hello, Audio Guru.
>>>
>>> Please review the fix for jdk9.
>>> While working on some bugs reported by the mach5 project, I found that
>>> some of our tests are quite unstable, and the reason was in this(or
>>> similar) pattern:
>>> ....
>>> clip.start();
>>> while(clip.isRunning());
>>> ....
>>> The status of the clip is run or not is updated on a different thread,
>>> but our clip implementation lacks of synchronization of getters and
>>> the hotspot inline such methods to while(true). There are some other
>>> flags which have the similar issue, I tried to fix all of them in the
>>> proposed version of the fix.
>>>
>>> Also I propose the small cleanup of Sequence.java
>>>  - It is not necessary to sync tracks.removeElement() on tracks,
>>> because this is synchronized method.
>>>  - tracks.toArray(new Track[tracks.size()]) should be synchronized on
>>> tracks, because the problem can occurs between tracks.size() and
>>> tracks.toArray(). But I decided to pass the empty array, so all the
>>> work will be done in toArray() which is synchronized method.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156169
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8156169/webrev.01
>>>
>>>
>>
>
>