[concurrency-interest] ReadWriteLock Deadlock Detection Flaws?

Sam Berlin sberlin at gmail.com
Fri Jun 26 23:57:03 EDT 2009


True, but to me there's a difference between that and deadlock.  It's
perfectly valid for one thread to lock the readLock and another to lock the
writeLock -- the latter thread just waits until the former closes the lock.
What's invalid (and is deadlock without any question) is when each thread is
prevented from acquiring the next lock because the thread that is holding
the lock is trying to acquire the opposite lock.

Although I don't consider a single thread holding readLock and then
attempting to acquire writeLock the same situation as a classic deadlock
scenario, I wouldn't be against the VM also reporting that as a stalled
thread in a deadlock report.

Sam

On Fri, Jun 26, 2009 at 10:57 PM, Cleber Muramoto <cleber at nightcoders.com.br
> wrote:

> I think the locks are only individually reentrant.
>
> Even a single thread will 'deadlock' if the oposite lock isn't
> unlocked before acquiring the intended lock.
>
> On Fri, Jun 26, 2009 at 1:00 PM,
> <concurrency-interest-request at cs.oswego.edu> wrote:
> > Send Concurrency-interest mailing list submissions to
> >        concurrency-interest at cs.oswego.edu
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > or, via email, send a message with subject or body 'help' to
> >        concurrency-interest-request at cs.oswego.edu
> >
> > You can reach the person managing the list at
> >        concurrency-interest-owner at cs.oswego.edu
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Concurrency-interest digest..."
> >
> >
> > Today's Topics:
> >
> >   1. ReadWriteLock Deadlock Detection Flaws? (Sam Berlin)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 26 Jun 2009 10:13:39 -0400
> > From: Sam Berlin <sberlin at gmail.com>
> > Subject: [concurrency-interest] ReadWriteLock Deadlock Detection
> >        Flaws?
> > To: concurrency-interest <concurrency-interest at cs.oswego.edu>
> > Message-ID:
> >        <19196d860906260713o10ef85e5ya08f6e5529d65ed1 at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > There seem to be some classic scenarios of deadlock where the VM doesn't
> > detect deadlock.  With the following two threads:
> >
> >   new Thread(new Runnable() {  // Thread 1
> >            @Override
> >            public void run() {
> >                System.out.println("t1 locking a");
> >                a.lock();
> >                try {
> >                    System.out.println("t1 locked a");
> >                    try {Thread.sleep(1000); } catch(Exception e) {}
> >                    System.out.println("t1 locking b");
> >                    b.lock();
> >                    try {
> >                        System.out.println("t1 locked b");
> >                        try {Thread.sleep(100000); } catch(Exception e) {}
> >                    } finally {
> >                        b.unlock();
> >                    }
> >                } finally {
> >                    a.unlock();
> >                }
> >            }
> >        }).start();
> >
> >        new Thread(new Runnable() {  // Thread 2
> >            @Override
> >            public void run() {
> >                System.out.println("t2 locking b");
> >                b.lock();
> >                try {
> >                    System.out.println("t2 locked b");
> >                    System.out.println("t2 locking a");
> >                    a.lock();
> >                    try {
> >                        System.out.println("t2 locked a");
> >                        try {Thread.sleep(100000); } catch(Exception e) {}
> >                    } finally {
> >                        a.unlock();
> >                    }
> >                } finally {
> >                    b.unlock();
> >                }
> >            }
> >        }).start();
> >
> > This prints out:
> >  t1 locking a
> >  t1 locked a
> >  t2 locking b
> >  t2 locked b
> >  t2 locking a
> >  t1 locking b
> >  [and flow halts because of deadlock]
> >
> > In the simple case of 'a' and 'b' being simple ReentrantLocks (or Objects
> > and using synchronize()), the VM correctly finds a deadlock.  If 'a' and
> 'b'
> > are ReentrantReadWriteLocks, there are some conditions where it will not
> > find a deadlock.
> >
> > Here's the possible deadlocking scenarios and the result:
> >  Thread 1 & Thread 2 all lock writeLock ---> VM finds deadlock
> >  Thread 1 locks all writeLocks, Thread 2 'b' locks writeLock, 'a' locks
> > readLock --> VM finds deadlock
> >  Thread 1 locks all writeLocks, Thread 2 'b' locks readLock , 'a' locks
> > writeLock--> NO DEADLOCK FOUND
> >  Thread 1 locks all writeLocks, Thread 2 locks all readLocks --> NO
> > DEADLOCK FOUND
> >  Thread 1 'a' locks writeLock, 'b' locks readLock, Thread 2 locks all
> > writeLocks --> VM Finds deadlock
> >  Thread 1 'a' locks readLock, 'b' locks writeLock, Thread 2 locks all
> > writeLocks --> NO DEADLOCK FOUND
> >  Thread 1 locks all readLocks, Thread 2 locks all writeLocks --> NO
> > DEADLOCK FOUND
> >  Thread 1 'a' locks writeLock, 'b' locks readLock, Thread 2 'b' locks
> > writeLock, 'a' locks readLock --> VM finds deadlock
> >  Thread 1 'a' locks readLock, 'b' locks writeLock, Thread 2 'b' locks
> > readLock, 'a' locks writeLock --> NO DEADLOCK FOUND
> >
> > The pattern seems to be that whenever a deadlock would be encountered due
> to
> > out-of-order locking, if the readLock was locked before a
> deadlock-inducing
> > writeLock, then no deadlock is found.  Conversely, if the writeLock is
> > locked before the deadlock-inducing readLock, the VM does find deadlock.
> >
> > This is with JDK 1.6.0_12-b04.
> >
> > Is this a known issue, a bug, or something else?
> >
> > Thanks much,
> >  Sam
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090626/bc807c9e/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> > End of Concurrency-interest Digest, Vol 53, Issue 29
> > ****************************************************
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090626/abd6b1ae/attachment.html>


More information about the Concurrency-interest mailing list