[concurrency-interest] ReadWriteLock Deadlock Detection Flaws?

Cleber Muramoto cleber at nightcoders.com.br
Fri Jun 26 22:57:22 EDT 2009


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
> ****************************************************
>
>



More information about the Concurrency-interest mailing list