ReadWrite Locks

Skip to first unread message

Todd Lipcon

Mar 8, 2010, 4:11:58 PM3/8/10
Hi all,

Recently I've become interested in adding support for the locks in
java.util.concurrent.locks to JCarder. Dealing with ReentrantLock
should be simple - I can simply subclass it, and rewrite any
construction of ReentrantLock to construct the subclass instead. The
tracing of lock() and unlock() in the subclass is then the same as the
existing monitorEnter and monitorExit.

The trickier thing to deal with (and equally important for my use
case) is ReentrantReadWriteLock. I discussed this issue with some of
my colleagues and we came up with the following reduction:

1) Split every ReadWriteLock X into two locks, and X.write. In
the split locks, keep a boolean for whether it's the "read half" or
"write half".
2) If a thread acquires, simply trace it as such in the lock
acquisition graph.
3) If a thread acquires X.write, record it as first an acquisition of, and then an acquisition of X.write.
4) When analyzing cycles, apply the rule: If a cycle includes any
"read half", then X.write must also be in the cycle. If not,
the cycle cannot deadlock.

Has anyone else thought about this problem? It's very interesting to
reason through, and also will be important for my use of JCarder in an
application that makes heavy use of these lock types.


Todd Lipcon

Mar 12, 2010, 3:48:32 AM3/12/10
In case anyone's interested, I've pushed preliminary work for this project here:

It vaguely works, but very lacking in tests and polish.


Jan 23, 2013, 10:19:08 AM1/23/13
It's been a while, but I recently took Todd's work on this and cleaned it up a bit. 

The main additions are:

* Support for java.util.concurrent locks.
* Report line numbers for lock acquisition.
* Make the analyzer tolerant of corrupted context DBs, since I found that sometimes not all the entries were written at shutdown.
* Log the Java args used to invoke the agent JVM - useful for discovering which test is being run when running a suite of tests with Ant or Maven. 

I also fixed the unit tests and added a new one for ReentrantLock. I ran jcarder with these modifications using the Hadoop test suite and it completed successfully and found the current known set of potential deadlocks.

Are folks interested in getting these changes back into jcarder itself?


Todd Lipcon

Jan 23, 2013, 1:24:27 PM1/23/13
to Tom White,
Cool, thanks Tom! I'm about to leave on a short vacation tomorrow but will try to review your changes in the next couple of weeks.

I'll leave it up to the official maintainers whether to integrate this in the mainline, though.

Reply all
Reply to author
0 new messages