Avoiding deadlocks in concurrent programming

[Paul McGuire]

Using an RDBMS is no cure-all for deadlocks - I can just as easily
deadlock with an RDBMS as with my own threads and locks, probably
easier.

I try to pick up crumbs of knowledge from my co-workers, and one of the
smarter ones gave me this rubric for testing for deadlocks.  You need 3
things to create deadlock:
1. multiple locks
2. multiple threads of execution
3. mixed access order to the locks (process 1 has lock A and wants lock
B, while concurrently process 2 has lock B and wants A)

So to avoid deadlock, invert the rubric and get rid of any one of these
elements.  One proposed solution was to use a single global lock - this
would cancel out criteria number 1.  An alternative might be to get rid
of multiple threads.  Your current design uses a background thread, but
if this could be merged in some round-robin fashion with the other
needed processing (a generator pool perhaps?), then you could try door
#2.  If you don't like either of these options, then look at ways to
ensure locks are always acquired in the same order - perhaps
alphabetically by resource name, or top-down if organized
hierarchically - to ensure that locks are never acquired in mixed
order.  In the case of processes 1 and 2, if all locks were to be
acquired alphabetically, then process 2, holding B and wanting A, would
have to first release B, then request A and then re-request B.  This
would break the deadlock with process 1.

I don't know if I've really offered anything new, but at least you have
some structure with which to approach your question.

-- Paul