What's an "atomic" operation (in a threaded context)?

[Parzival]

Dieter Maurer wrote:

> Peter Hansen <peter at engcorp.com> writes on Wed, 12 Nov 2003 17:49:10
-0500:
>> >               9 STORE_SUBSCR
>> In a nutshell, your "single bytecode operation" theory is correct,
>> and each of the above lines represents a single bytecode.  Therefore
>> the only line which matters is STORE_SUBSCR (the actual assignment)
>> and it is atomic
> 
> Are you sure? "STORE_SUBSCR" may dereference an object causing
<snip> 
> Almost surely (I trust the Python developpers), this happens
> after the assignment has been made (but before "STORE_SUBSCR" finished).
> Maybe, this is enough "atomicity" for you.

Do you really think this is a sound approach? You are obviously concerned
about correct concurrency, yet you are prepared to disassemble Python byte
code and to speculate about the actions, and then you are going to risk the
correctness of your program on what you observe and deduce?

I'll wager that nobody who is somebody in the Python world is going to offer
*any* guarantees about what source code generates what byte-code. AFAIK,
the Python GIL guarantees that at least one bytecode operation is atomic,
but the _language_ makes absolutely no commitments as to what source code
construction is guaranteed to be (now and forever) atomic. If I am wrong
about this, I want to see it in writing in the official documentation.

Until then, for correct concurrent operation, you *must* lock around all
shared concurrent data accesses.

(-: Stop, smile, and enjoy your breathing :-)
-- Parzival
-- Reply-to is confuggled: parzp (@) shaw (.) ca