atomic operations in presence of multithreading

Dave Brueck dave at
Wed Jul 28 00:16:47 CEST 2004

Paul Moore wrote:
> Peter Hansen <peter at> 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.

Yep, though I think the OP was mostly concerned with Python's internals 
gettin messed up by unlocked multithreaded access, so he doesn't have to 
be concerned about the above.


More information about the Python-list mailing list