I'm already somewhat unhappy at the complexity of the code; I'd prefer not
to make it any more complicated. I think race conditions on the write lock
are going to be pretty rare and probably only occur on a somewhat saturated
server at initial startup. I think twisting the code ever further.
In addition, in a ReentrantReadWriteLock, the write lock appears to return
false if any thread has the read lock, which could result in
the initialization code never being run.
On Thu, Jun 14, 2012 at 2:36 AM, Denis Stepanov <denis.stepa...@gmail.com>wrote:
> Concurrency topic:
>
> Would it be possible to change the lazy init to check if write lock is
> already locked? It will eliminate the posibility of locking the write lock
> by more then one thread.
>
> try {
>
> readLock.lock();
>
> if(is need to init)
> {
> boolean hasWriteLock = false;
> try {
> readLock.unlock();
> hasWriteLock = writeLock.tryLock(); // Could be locked
> only once
> if(hasWriteLock)
> doInit();
> } finally
> {
> if(hasWriteLock)
> writeLock.unlock();
>
> readLock.lock(); // If the write lock is locked read threads
> will wait
> }
> }
> return ...
>
> } finally
> {
> readLock.unlock();
> }
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
