On Tue, 24 Jun 2025 12:50:14 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>>>What I mean is two threads that called GraphicsDevice.getFullScreenWindow >>>still established a happens-before relation for each call, which will be >>>gone with the volatile modifier. >>>It may be fine… or may be not… this is why I'm asking. >> >> 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. > >> 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(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2164556539
