Avoiding deadlocks in concurrent programming

[Paul Rubin]

"Eloff" <eloff777 at yahoo.com> writes:
> >If the 100 threads are blocked waiting for the lock, they shouldn't
> >get awakened until the lock is released.  So this approach is
> >reasonable if you can minimize the lock time for each transaction.
> 
> Now that is interesting, because if 100 clients have to go through the
> system in a second, the server clearly is capable of sending 100
> clients through in a second, and it doesn't matter if they all go
> through "at once" or one at a time so long as nobody gets stuck waiting
> for much longer than a few seconds. It would be very simple and
> painless for me to send them all through one at a time. It is also
> possible that certain objects are never accessed in the same action,
> and those could have seperate locks as an optimization (this would
> require carefull analysis of the different actions.)

If you can design the transactions to not need anything like I/O
waiting while a lock is being held, you may as well just use a single
lock.  Even more Pythonically, have a single thread "own" the
structure and let other threads send requests through a Queue object
and get replies through another Queue.  Even on a multiprocessor
system, CPython (because of the GIL) doesn't allow true parallel
threads, so it's ok to serialize access to the structure that way.

If you need/want real parallelism on a multiprocessor, see
http://poshmodule.sf.net but then you start needing fancier
synchronization.