From: Martin D. <mar...@ge...> - 2007-07-03 11:26:02
|
Jody Garnett a écrit : > writeLock is a more "serious" locking condition (only one is allowed > in); by using a read lock we can capture many more threads in the "get" > method (where many threads are allowed in once reading is available > again). The effect is on if the map allows concurrent access or not ... > > I am a bit confused Martin - why are we talking about this? Did the > sequence diagrams not work out? Or am I not understanding your suggestion? I understand the sequence of "readLock()", "writeLock()", "get()" and "peek()" you described. My point is that you don't need the read lock at all for achieving exactly what you want to achieve, and consequently ObjectCacheEntry don't need to hold a ReadWriteLock, and consequently ObjectCacheEntry itself may not be needed. My point is that in every use case I found, you don't need to acquire a read lock before entering in the "get" method. Neither a write lock. You don't need a lock at all. If the object is in process of being calculated, "get()" will returns null immediately (no blocking). The execution enter in the "if (foo == null)" code and block immediately on the "writeLock()" line. So you get everything you want (invoking the "get" method concurently, waiting if the object is in process of being created in an other thread) without the need for a read lock, and consequently without the need for ReadWriteLock. A single Lock, or a plain synchronized statement where you use the writeLock, would work as well. Martin |