[Python-Dev] PyFAQ: thread-safe interpreter operations

["Martin v. Löwis"]

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