[concurrency-interest] Java Deadlocks prevented

Nathan Reynolds nathan.reynolds at oracle.com
Mon Apr 16 13:11:00 EDT 2012

Deadlock prevention is very valuable.  It means deadlock prone code 
won't bring down a production server and cost the company millions in 
down time.  It means consumers won't kill the process and request a refund.

How much does deadlock prevention cost?  Is the cost on the thread that 
acquires locks or is it in a background thread?

Each time processors or systems increase the number of cores, I find we 
have to do a round of lock contention fixing.  I have only seen 1 lock 
at a time be the bottleneck in the system.  Does deadlock prevention 
increase the critical region of locks?  If so, this will definitely 
reduce the scalability of the system if it impacts the 1 bottlenecking lock.

Lock performance is a very important consideration.  Locks have evolved 
from fat locks (i.e trips into the OS kernel) to thin locks (i.e. spin 
and CAS in user mode) to biased/lazy locks (i.e. no CAS and an 
indefinite lock owner).  All of this was done to reduce the performance 
overhead of locks.  How does deadlock prevention impact the performance 
of biased, thin and fat locks?  I am not as concerned about fat lock 
performance since most of the time the thread is going to block.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 4/16/2012 9:38 AM, Boehm, Hans wrote:
> Important questions to consider when you write it up:
> How does it compare to something like Gadara that uses whole program analysis and scheduling to avoid lock-based deadlocks?  (Hopefully it doesn't need whole program analysis.)  Other deadlock avoidance schemes?
> Once you detect a potential deadlock, how do you recover?  Or can you always schedule so that the possibility doesn't arise?
> Hans
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
>> interest-bounces at cs.oswego.edu] On Behalf Of Andrew Haley
>> Sent: Monday, April 16, 2012 4:34 AM
>> To: concurrency-interest at cs.oswego.edu
>> Subject: Re: [concurrency-interest] Java Deadlocks prevented
>> On 04/16/2012 12:06 PM, Rohit Kumar wrote:
>>> I have found a way of preventing deadlocks in java. The
>>> methodology(which is code) completely prevents the deadlock from
>>> occuring by detecting it in advance. This can be used across the
>>> systems seamlessly.
>>> Kindly let me know what I need to do next. I want this to be part of
>>> next jdk release. I am writing this email as I have no idea what I
>>> need to do next to bring it into limelight.
>> Write it up, maybe present it to a conference, and wait for feedback.
>> That's how it always works.  If your idea really works, people will
>> use it.
>> Andrew.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> 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/20120416/7ea89bb3/attachment.html>

More information about the Concurrency-interest mailing list