atomic operations in presence of multithreading

[Paul Moore]

Peter Hansen <peter at engcorp.com> writes:

> Dave Brueck wrote:
>
>> Glenn Kasten wrote:
>>
>>> I am wondering which operations in Python
>>> are guaranteed to be atomic in the presence
>>> of multi-threading. In particular, are assignment
>>> and reading of a dictionary entry atomic?
>>
>  > [...]
>> Basically: multiple threads can't corrupt the interpreter's
>> internals (but a buggy C extension could).
>

[...]

> The key instructions in the above are the dictionary lookup,
> which is merely "BINARY_SUBSCR" in func(), and the dictionary
> assignment, which is "STORE_SUBSCR" in func2().  If func
> and func2 were in separate threads, either the lookup or
> the store executes first, then the other, but they cannot
> both be executing at the same time.

As was pointed out to me when this came up recently, it is possible
for callbacks into python to screw this simple picture up a little.

The obvious case is a user-defined class with a __setitem__ method. In
this case, STORE_SUBSCR calls arbitrary Python code, and so can be
interrupted by a thread switch.

Given that the original question was about dictionaries, which are
coded in C (and so not subject to this issue) there is still the
following case: when the old value stored in the dictionary is
replaced, that could be the last reference to it. When the old value
is freed, its __del__ method gets called - arbitrary Python code
again.

But the basic idea is sound. The interpreter releases the GIL *only*
between Python bytecodes. As long as you cater for recursive cases
like the above (and obvious ones like CALL_METHOD), you're OK.

Finally, C code has the option of explicitly releasing the GIL -
"long-running" operations like file reads do this, but basic ops
don't.

Paul.
-- 
This signature intentionally left blank