-
Bug
-
Resolution: Fixed
-
P4
-
5.0
-
b49
-
generic
-
solaris_9
Throughout the XAWT source code, there are two approaches to entering the "AWT lock".
The first uses the traditional synchronized keyword:
synchronized (XToolkit.getAWTLock()) { ...
The second approach delegates to the XToolkit.awtLock/Unlock() methods (which
in turn make use of the Unsafe.monitorEnter/Exit() methods):
XToolkit.awtLock();
try {
...
} finally {
XToolkit.awtUnlock();
}
While the first form is more succinct, it is not as flexible as the second form.
Since both forms are used throughout the XAWT code, we should choose one and stick
with it. I'm proposing to convert all code in the first form to use the more
flexible second form. Not only does it make the code more consistent throughout,
it also opens up the possibility of using a more advanced locking mechanism in the
future (could be helpful in fixing 6253009 and related bugs).
The first uses the traditional synchronized keyword:
synchronized (XToolkit.getAWTLock()) { ...
The second approach delegates to the XToolkit.awtLock/Unlock() methods (which
in turn make use of the Unsafe.monitorEnter/Exit() methods):
XToolkit.awtLock();
try {
...
} finally {
XToolkit.awtUnlock();
}
While the first form is more succinct, it is not as flexible as the second form.
Since both forms are used throughout the XAWT code, we should choose one and stick
with it. I'm proposing to convert all code in the first form to use the more
flexible second form. Not only does it make the code more consistent throughout,
it also opens up the possibility of using a more advanced locking mechanism in the
future (could be helpful in fixing 6253009 and related bugs).