aboutsummaryrefslogtreecommitdiffstats
path: root/make/scripts/java-win64.bat
diff options
context:
space:
mode:
authorSven Gothel <[email protected]>2012-05-13 20:00:21 +0200
committerSven Gothel <[email protected]>2012-05-13 22:05:35 +0200
commitdf6c9accd84b801d86c8f6f9ce35e02ffd417f71 (patch)
tree9dd593bf6ed9631ef8ac723b5e07c87ae3e347d7 /make/scripts/java-win64.bat
parent78d9e7c84f03ac7b83ad2933cac884ce9ecac161 (diff)
GLContext*: Remove '[set/is]Synchronized(..)' - Defaults to wait for locks: 1. Drawable, 2. GLContext
Remove deadlock situation where thread-1 (Animator Thread) holds the GLContext-Lock and acquires the Surface-Lock, while thread-2 (UI/Main/EDT) holds the Surface-Lock and attempts to create the GLContext and hence acquires the GLContext-Lock. A GLContext-Lock and hence makeing the GLContext current requires to hold the Surface-Lock. The prev. code acquired the locks in reverse order and allowed the deadlock as described above. This fix acquires the locks in the proper natural order 1 - Surface-Lock 2 - GLContext-Lock This fix also renders the use of the non-synchronized behavior invalid, since it is bogus not to wait for the GLContext lock where it waits for the Surface lock. It also seems nonsense not to wait for any of both locks and our code always waited for both (synchronized := true). The GLContext [set/is]Synchronized(..) methods are removed and waiting for the lock per default is the correct behavior.
Diffstat (limited to 'make/scripts/java-win64.bat')
0 files changed, 0 insertions, 0 deletions