atomic operations in presence of multithreading

[Dave Brueck]

Paul Moore wrote:
> 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.

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.

-Dave