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

["Martin v. Löwis"]

Robert Brewer schrieb:
> The confusion arises because transactional theory uses "atomic
> transaction" in a much narrower sense than language design uses the
> phrase "atomic operation" (see
> http://en.wikipedia.org/wiki/Atomic_operation for example--it
> includes isolation and consistency). And the FAQ entry is only
> addressing the "isolation" concern; whether or not a given operation
> can be interrupted/overlapped. Those who design thread-safe
> containers benefit from such a list. Yes, they must also make sure no
> Python code (like __del__ or __setattr_, etc) is invoked during the
> operation; others have already pointed out that by using builtins,
> this can be minimized. But that "second step" doesn't negate the
> benefit of the "first step", eliminating statements which require
> multiple VM instructions.

Ok. I think I would have understood that FAQ entry better if it
had said: "These operations are represented in a single byte-code
operation", instead of saying "they are thread-safe", or "they are
atomic". Of course, Josiah Carlson's remark then still applies:
all statements listed there take multiple byte codes, because
you have to put the parameters onto the stack first.

This is more than hypothetical. If two threads do simultaneously

thread1            thread2
x = y              y = x

then, if these were "atomic", you would expect that afterwards,
both variables have the same value: Either thread1 executes
first, which means that x has the value of y (and thread2's
operation has no effect), or thread2 executes first, in which
case both variables get x's original value.

However, in Python, it may happen that afterwards, the values
get swapped: thread1 loads y onto the stack, then a context
switch occurs, then thread2 sets y = x (so y gets x's value),
later thread1 becomes active again, and x gets y's original
value (from the thread1 stack).

If you were looking for actions where the "core" operation
is a single opcode, then this list could be much longer:
all of the following are "atomic" or "thread-safe", too:

unary operations (+x, -x, not x, ~x)
binary operations (a+b,a-b,a*b,a/b,a//b,a[b])
exec "string"
del x
del x.field
del x[i]

As for the original questions: "x+=1" is two "atomic"
operations, not one. Or, more precisely, it's 4 opcodes,
not 2.

Regards,
Martin