A couple of footnotes to last mail...
1. It is generally more convenient for thread W in the illustrated
scenario to perform extra notifications after it re-acquires lock
rather than before. The order here doesn't otherwise matter.
2. In the illustrated scenario, note that extra notifications are not
needed if thread W can determine that it lost out to a notifyAll, not
a notify.
3. The leakiness of underlying blocking mechanisms is reflected in
JSR-166 java.util.concurrent.locks.LockSupport.{park,unpark}, which is
the ONLY Java blocking mechanism available for people building
customized locks and related synchronization aids. (Like atomics
support, these are in a for-infrastructure-developers-only
subpackage). Thread.suspend/resume are useless for such purposes and
are in any case deprecated. Developers of customized locks will
want/need to obtain semantics compatible with builtin locks and
monitors.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT