Larry K. Wollensham <lkw4096@gmail.com> wrote:
Andreas Leitgeb wrote:
Remains one further approach: Active deadlock-detection by the VM.
If the current Thread (t1) is holding the lock of (at least) one object
(o1), and attempts to aquire another lock (of o2) and if this object(o2)'s
lock is currently held by another thread (t2), then (after t1 is registered
as waiting for o2) a cycle-search is performed, by going from Object (o_n)
to its holding Thread (t_n) to that's newly-waited-for Object (o_(n+1)) to
that's holding Thread (t_(n+1)) ... until either of these conditions is met:
1) A Thread *not* currently waiting for any object's lock,
2) the first Thread (t1) re-encountered.
In case 1), everything's normal, and t1 remains in wait state for o2.
In case 2), t1's waiting for o2 inevitably leads to a deadlock, so
an error would be thrown from the synchronized()-statement (or
monitorenter at bytecode level)
There should not exist a case 3) where the chain leads into a cycle
not involving t1, unless something went awfully wrong earlier.
It would still be programmer's responsibility to not catch that error
too early (i.e. inside the block still holding the first lock) and
immediately reattempt getting the other lock again.
Actually, that is exactly what I would do. I'd note which synchronized
generated the error, then wrap it in a try-catch and a loop and rerun it.
If you catch it inside the block that already (and still) holds the first
lock, then on next iteration of that loop, you'll definitely see exactly
the same error at the same spot again. Why? All the other threads are
directly or indirectly still waiting on the lock held by our current thread,
so it will be a completely deterministic case of the error being rethrown
for the same thread at the same place.
If you catch'n'retry far enough outside, i.e. outside the synchronized scope
of the first relevant lock, then there s a chance for the next attempt to be
successful, or at least a different thread banging next time, now disclosing
valuable data for diagnosis.
areas, transactional memory. The idea is to treat memory like a
transactional database. Parallel programming would be done in terms of
transactions. There is an article on the subject in the February
Drepper, U. 2009. Parallel programming with transactional memory.
Commun. ACM 52, 2 (Feb. 2009), 38-43. DOI=