Re: JavaMemoryModel: Proposed wording on lost interrupts

From: Doug Lea (
Date: Sun Aug 10 2003 - 10:29:33 EDT

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


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT