On 23/01/2024 16:56, Jurgen Doll wrote:
Hi John and others,
I don't think we are entirely on the same page, so here's the objective.
The Goal: To determine if the FX animation thread and a SINGLE other
thread can access Animation in a safe manner wrt play, stop, and resume.
The number of threads is irrelevant really, it's either thread safe or
it isn't.
Non Goal: Multi-threaded access of Animation play, stop, and resume is
NOT a goal.
Wrt play() and resume(), it is ALWAYS safe to call them on a
background thread because at this point the Animation isn't being
processed by the FX thread as the "Animation" isn't contained in the
AbstractPrimaryTimer receivers array.
I'm afraid that is incorrect. The fact that your animation is not
running doesn't mean that AbstractPrimaryTimer isn't in use by other
animations that are running. These other animations are using the
receivers array, and may be modifying it or reading from it from the FX
thread.
When you start your animation on a different thread, you are accessing
these fields with a different thread, and modifying them. Since the JVM
is free to cache values and do other fancy things (like reordering
read/writes) in the absence of synchronized/locking, there is no
guarantee that the FX thread will see those modifications until these
are flushed to main memory (or caches are synced). Even then, the FX
thread may have these values cached somewhere, and so it may not go all
the way to main memory to see if its assumptions are now incorrect. The
only way to ensure this is with proper use of synchronization.
So a hypothetical scenario:
- AbstractPrimaryTimer has no receivers
- A receiver is added via the FX thread, slot 0 is now filled and
receiversLength is now 1. Due to cache lines being large, it also read
slot 1 (which is null)
- You start your animation on another thread. Since you didn't see the
receivers array yet, you may see one of these states:
- The change from the FX thread was flushed to main memory, and you
see [X, null] and receiversLength = 1
- The change from the FX thread was partially flushed, and you see
[X, null] and receiversLength = 0 (!!)
- Nothing was flushed yet, and you see [null, null] and
receiversLength = 0
Now, you can see that it would be very dangerous to proceed to modify
the array based on half flushed information. Something similar happens
when you are the first to start an animation, and then another is
started later. If the changes of your thread are not flushed yet (or
partially) then the FX thread will act on partially flushed data, or
even see no receivers yet at all...
--John
