Right, I should known that it will not lock when there are some readers.
Denis
Jun 14, 2012 v 7:28 PM, Howard Lewis Ship:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
