On Tue, 24 Jun 2025 17:34:54 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>>> That only affects the case where the second thread tries to read shared >>> data (unrelated to GraphicsDevice) without synchronization, which was >>> written before the first thread called getFullScreenWindow(). If visibility >>> is required, it should be ensured by the caller. Depending on some internal >>> and undocumented lock for that is not a good thing. >> >> It is true… but it affects the fields of the full screen window itself. >> Doesn't any code path uses the fields of the full screen window after >> getting an object reference to it? > > Window fields may be modified at any time by different threads, such as the > EDT, Toolkit thread, or others. Without proper synchronization, this can lead > to race conditions. Even in the scenario we discussed where > getFullScreenWindow() is called twice a race condition can still occur. For > example if the first thread modifies the Window and then calls > getFullScreenWindow(), and at the same time, a second thread also calls > getFullScreenWindow() and attempts to read the Window's fields, a race may > occur if the first thread begins modifying the Window again before its next > call to getFullScreenWindow(). Yes, I agree race conditions and memory inconsistencies are still in place, however, the synchronized block brought the state of the full screen object to a fresher state. I looked through the usages of `getFullScreenWindow()` and couldn't find any usages of full screen window fields, so a `volatile` modifier seems appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2166941317
