[concurrency-interest] problem with ReentrantReadWriteLock toimplement atomic function

Joe Bowbeer joe.bowbeer at gmail.com
Tue Jun 20 05:50:37 EDT 2006

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.)


Was the write lock getting downgraded correctly?

  if (!hasValue) {
      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