[Python-Dev] PyFAQ: thread-safe interpreter operations (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue Nov 21 19:41:50 CET 2006

Armin Rigo schrieb:

I think this list of examples isn't meant to be read that way. Half of them can invoke custom methods, not just the two you mention here. I think the idea is that provided only "built-in enough" objects are involved, the core operation described by each line works atomically, in the sense e.g. that if two threads do 'L.append(x)' you really add two items to the list (only the order is unspecified), and if two threads perform x.field = y roughly at the same time, and the type of x doesn't override the default setattr logic, then you know that the object x will end up with a 'field' that is present and has exactly one of the two values that the threads tried to put in.

Ah, so it's more about Consistency (lists not being corrupted) than about Atomicity (operations either succeeding completely or failing completely). Perhaps it's also about Isolation (no intermediate results visible), but I'm not so sure which of these operations are isolated (given the callbacks).

Python programs rely on these kind of properties, and they are probably a good thing - at least, much better IMHO than having to put locks everywhere. I would even say that the distinction between "preventing the interpreter from crashing" and "getting sane results" is not really relevant. If your program doesn't crash the interpreter, but loose some append()s or produce similar nonsense if you forget a lock, then we get the drawbacks of the GIL without its benefits...

So again, I think it's consistency you are after here (of the ACID properties).

In practice, the list of operations that is atomic should (ideally) be documented more precisely -- one way to do that is to specify it at the level of built-in methods instead of syntax, e.g. saying that the method list.append() works atomically, and so does dict.setdefault() as long as all keys are "built-in enough" objects.

But many of these operations don't work atomically! (although .append does) For example, x = y may cause del for the old value of x to be invoked, which may fail with an exception. If it fails, the assignment is still carried out, instead of being rolled back.

Regards, Martin

More information about the Python-Dev mailing list