On Tue, 4 Mar 2025 16:19:49 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> https://en.wikipedia.org/wiki/Cache_coherence That's interesting, but not particularly relevant. What is relevant is the JVM spec, specifically the Java Memory Model, which guarantees a happens-before ordering of actions in two threads that synchronize-with each other. > edit: you might be right about runAndWait, we know it does separate the > access from multiple threads in time, and it might be even smart enough to > figure out that the field is being accessed from two different threads and > emit the appropriate bytecode (similarly how we don't need the `final` > keyword for effectively final variables nowadays). It isn't about the byte code that is emitted as much as it is about how the code is executed by the two different threads. And it isn't because it need to be "smart enough", it's because that's how the memory model works. A write by the thread that executes the runnable passed into runAndWait (the FX app thread in this case), happens-before the read done by the test thread that is done after the runAndWait returns because the runAndWait call causes the actions done in the runAndWait's runnable to synchronize-with the wait done by the calling thread. > But I think that adding `volatile` **_guarantees_** that all the necessary > steps are done by the JVM. Yes, adding `volatile` guarantees the appropriate happens-before relationship. But so does synchronizing. I don't really care one way or the other in this case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979939639
