[Python-Dev] Threading idea -- exposing a global thread lock (original) (raw)
Raymond Hettinger raymond.hettinger at verizon.net
Tue Mar 14 03:57:59 CET 2006
- Previous message: [Python-Dev] checkin r43015
- Next message: [Python-Dev] Threading idea -- exposing a global thread lock
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
A user on comp.lang.python has twisted himself into knots writing multi-threaded code that avoids locks and queues but fails when running code with non-atomic access to a shared resource. While his specific design is somewhat flawed, it does suggest that we could offer an easy way to make a block of code atomic without the complexity of other synchronization tools:
gil.acquire() try: #do some transaction that needs to be atomic finally: gil.release()
The idea is to temporarily suspend thread switches (either using the GIL or a global variable in the eval-loop). Think of it as "non-cooperative" multi-threading. While this is a somewhat rough approach, it is dramatically simpler than the alternatives (i.e. wrapping locks around every access to a resource or feeding all resource requests to a separate thread via a Queue).
While I haven't tried it yet, I think the implementation is likely to be trivial.
FWIW, the new with-statement makes the above fragment even more readable:
with atomic_transaction():
# do a series of steps without interruption
Raymond
- Previous message: [Python-Dev] checkin r43015
- Next message: [Python-Dev] Threading idea -- exposing a global thread lock
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]