On Thu, 10 Feb 2022 23:57:29 GMT, Phil Race <[email protected]> wrote:
> This test has started failing since we got M1 macs to test on. I don't think
> we've ever seen this failure elsewhere.
> I don't know what it is about that architecture that makes it more likely but
> I can see how it can happen when multiple threads are using the same
> instance.
>
> if (newFramePosition >= 0) {
> clipBytePosition = newFramePosition * frameSize;
> newFramePosition = -1;
> }
>
> newFramePosition is declared volatile which does make it quite possible that
> after the read and before the use it will have changed.
>
> The fix just synchronizes this block to prevent it.
src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java line
1300:
> 1298: }
> 1299: while (doIO && thread == curThread) {
> 1300: synchronized (this) {
Maybe instead of synchronization we can read it to the local variable,then use,
then reset to -1? This class already has many different locks used for
synchronization and this one add another one for "this".
-------------
PR: https://git.openjdk.java.net/jdk/pull/7436
