Critical sections and mutexes

[brueckd at tbye.com]

On Wed, 24 Oct 2001, Skip Montanaro wrote:

>
>     dave> P.S. - Print statements are not atomic and do not fall in the same
>     dave> realm as "normal" Python operations (e.g. "i = 5") ...
>
> Assignment is not atomic either.  Your example would byte compile to
>
>     LOAD_CONST 5
>     STORE_FAST i

Ooh, good point, bad example from me. As far as atomicity, I was thinking
in terms of the C functions that implement the handling of the bytecodes
themselves (e.g. PyDict_SetItem - no two threads will call PyDict_SetItem
on the same dictionary at the same time).

> As others have mentioned, at the level of individual opcodes Python is
> atomic.  The statement
>
>     i = j
>
> would have to be protected if j could be rebound or the object j referenced
> could be modified by another thread.

Not necessarily. My point was simply that locking or no was mostly an
application-level requirement rather than a Python interpreter one. For
example (back to the producer/consumer example), assume that you have two
producers and a consumer that toggles between the producer lists called
'j' and 'k'.  If 'i' is the consumer's reference to whatever list it's
currently working on, you don't need any locking around 'i = j' even if
a producer happens to be modifying j at the "same time". Data won't be
lost, the interpreter won't die, etc, etc. That's all I was pointing out.

Thanks,
Dave