On Aug 26, 2008, at 5:23 AM, Martin Vysny wrote:
Many thanks for clarifying on how the locks works! One more question,
just to be 100% sure :) . Recently I studied the java memory model a
bit
(there is beautiful FAQ located at [1]) and I'd like to ask:
Let's assume that the execution exited some method m1 protected by
Lock.READ (or Lock.WRITE) and is about to enter some method m2 (in the
same Singleton bean) protected by Lock.WRITE. Is any operation invoked
in method m1 guaranteed to "happen-before" any operation invoked in
method m2?
Those details are better described on this page:
http://cwiki.apache.org/OPENEJBx30/singleton-beans.html
I've slightly tweaked it to make the connection with ReadWriteLock
stronger and to explicitly mention we use a ReentrantReadWriteLock.
Hopefully people will follow those links.
Here are a couple quotes from those docs that answer your questions a
little more specifically:
All ReadWriteLock implementations must guarantee that the
memory synchronization effects of writeLock operations (as
specified in the Lock interface) also hold with respect to the
associated readLock. That is, a thread successfully acquiring
the read lock will see all updates made upon previous release
of the write lock.
--
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html
Reentrancy also allows downgrading from the write lock to a
read lock, by acquiring the write lock, then the read lock and
then releasing the write lock. However, upgrading from a read
lock to the write lock is not possible.
--
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
We could probably quote some of those two javadocs if there were one
or two really critical things we think people should know above all
else. If you have any thoughts on that regard that'd be great.
-David
