Subj : Re: What does Memory Barriers mean ??
To   : comp.programming.threads
From : Alexander Terekhov
Date : Wed Jan 05 2005 04:41 am


Joe Seigh wrote:
[...]
> Speaking of JSR-166, why did they do that lock object 

<quote>

A Lock class can also provide behavior and semantics that is quite 
different from that of the implicit monitor lock, such as guaranteed 
ordering, non-reentrant usage, or deadlock detection. If an 
implementation provides such specialized semantics then the 
implementation must document those semantics. 

Note that Lock instances are just normal objects and can themselves 
be used as the target in a synchronized statement. Acquiring the 
monitor lock of a Lock instance has no specified relationship with 
invoking any of the lock() methods of that instance. It is 
recommended that to avoid confusion you never use Lock instances in 
this way, except within their own implementation. 

>                                                       with condvars?  

<quote>

newCondition

Condition newCondition() Returns a new Condition instance that is 
bound to this Lock instance. 

Before waiting on the condition the lock must be held by the current 
thread. A call to Condition.await() will atomically release the lock 
before waiting and re-acquire the lock before the wait returns. 

Implementation Considerations 

The exact operation of the Condition instance depends on the Lock 
implementation and must be documented by that implementation. 

</quote>

In JSR-166 you can have condvars bound to ReentrantReadWriteLock
(to its WriteLock, but not to its ReadLock).

regards,
alexander.

.