"Eloff" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
