[concurrency-interest] problem with ReentrantReadWriteLock toimplement atomic function

Joe Bowbeer joe.bowbeer at gmail.com
Tue Jun 20 07:28:50 EDT 2006


Conclusion:

I believe the missing writeLock.unlock is the root cause, resulting in
64K recursive write locks and ultimate failure.

I also wanted to mention that you don't need to use concurrent maps if
you're using your own locks.  Unsynch'd HashMap is fine.

On the other hand, ConcurrentMap provides some conditional put/remove
methods that you *might* be able to leverage.

Consider the following:

  V value2 = null;
  if (V_K.putIfAbsent(value, key)) {
      if ((value2 = K_V.put(key, value)) != null)
          V_K.remove(value2, key);
  }
  return value2;


On 6/20/06, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> On 6/20/06, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> > On 6/20/06, Kolbjørn Aambø <kaa at pax.priv.no> wrote:
> > >
> > > I suspect that the maximum number of locks (65536 recursive
> > > write locks and 65536 read locks) happen to be the problem here.
> > >
> >
> > That seems likely.  The exception was probably thrown from r.unlock()
> > inside a finally block -- after w.lock() or r.lock() threw an Error.
> >
> > (If you were to retain this code I'd suggest adding a "locked" flag
> > and/or more try-finally nesting in order to disambiguate this
> > condition. This would also protect against "put" failures, as David
> > points out.)
> >
>
> More:
>
> Was the write lock getting downgraded correctly?
>
>   if (!hasValue) {
>       r.unlock();
>       w.lock();
>       if (hasKey) V_K.remove(K_V.get(key));
>       V_K.put(value, key);
>       value2 = K_V.put(key, value);
>       r.lock(); // Downgrading the lock to read lock
>   }
>
> Isn't the above missing a final write unlock?
>
>     w.unlock(); // unlock write, still hold read
>
> The following is from ReentrantReadWriteLock javadoc:
>
>     // downgrade lock
>     rwl.readLock().lock(); // reacquire read without giving up write lock
>     rwl.writeLock().unlock(); // unlock write, still hold read
>



More information about the Concurrency-interest mailing list