[concurrency-interest] problem with ReentrantReadWriteLocktoimplement atomic function

David Holmes dcholmes at optusnet.com.au
Tue Jun 20 07:53:54 EDT 2006


And now that you've resolved the problem take a good look at where you need
to place try/catch/finally to ensure you won't attempt to unlock locks that
aren't locked if exceptions are thrown.

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Joe
> Bowbeer
> Sent: Tuesday, 20 June 2006 9:29 PM
> To: Kolbjørn Aambø
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] problem with
> ReentrantReadWriteLocktoimplement atomic function
>
>
> 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
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>




More information about the Concurrency-interest mailing list