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, X.read 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 X.read, simply trace it as such in the lock
acquisition graph.
3) If a thread acquires X.write, record it as first an acquisition of
X.read, and then an acquisition of X.write.
4) When analyzing cycles, apply the rule: If a cycle includes any
"read half" X.read, 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.
Thanks
-Todd
http://github.com/toddlipcon/jcarder/tree/lockclasses
It vaguely works, but very lacking in tests and polish.
-Todd