[concurrency-interest] LinkedBlockingDeque deadlock? (Test case)

David Holmes davidcholmes at aapt.net.au
Sat Jul 18 02:14:59 UTC 2009


Thanks very much for this.

When this "deadlocks" does top show whether the java process is actually
quiet or is it still consuming CPU? I notice that in the stack dump the main
thread is in the process of unlocking the lock that the other threads are
waiting upon and hence the system is not deadlocked - unless that main
thread is actually "stuck" somewhere. Can you take a series of stackdumps to
see if/how the main thread is executing?

Feel free to just send them to me rather than the mailing lists.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan
> Betts
> Sent: Saturday, 18 July 2009 2:48 AM
> To: concurrency-interest at cs.oswego.edu
> Cc: core-libs-dev
> Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
> case)
> Hello all,
> I've been working with Ariel on the j.u.c.LinkedBlockingDeque deadlock
> we observe. The attached test case reproduces the deadlock
> intermittently, usually requiring several minutes. The test simply
> prints periods until it deadlocks. Attempts to produce a simpler test
> case using only ReentrantLock or without an ExecutorService were
> unsuccessful.
> I've attached jstack reports showing the deadlocked case and the dmesg
> output from one of the servers that reproduces the defect. To date,
> this deadlock only occurs on our 2 socket i7s.
> We have not filed a defect with Sun for this issue. If that would be
> helpful (or necessary), we would of course happily oblige.
> $ java -version
> java version "1.6.0"
> OpenJDK  Runtime Environment (build 1.6.0-b09)
> OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
> $ uname -a
> Linux host3e 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009
> x86_64 x86_64 x86_64 GNU/Linux
> $ javac LBDLockPatternTest.java
> $ java LBDLockPatternTest
> Thank you,
> *--Ryan.

More information about the core-libs-dev mailing list