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

[Dave Brueck]

Paul Moore wrote:
> I can't find anything which spells this out in the manuals. I guess
> that, at some level, the answer is "a single bytecode operation", but

Bytecode instructions are atomic in that you won't switch to another Python
thread "mid-bytecode", but that's only sorta interesting.
;-)

> This thought was triggered by a comment on the Python Cookbook site,
> which basically said that it was OK to do
>     tss = {}
>     ...
>     id = thread.get_ident()
>     tss[id] = {}
>
> (where tss is a global) without a lock, because id is unique to the
> thread.
>
> But couldn't this result in 2 threads allocating a new entry in tss at
> the same time, and so get tss in an inconsistent state?

This is what's more interesting: object access is threadsafe in the sense that
you can't get Python's internal data structures into an inconsistent state via
pure Python code (or, for that matter, well-behaved C extensions). IOW, the
above code won't ever crash the interpreter or screw up Python's internal
state. Even if two different threads did tss[5] = <somevalue> (both setting a
value using the same key) you wouldn't get an inconsistent internal state,
although you would obviously have no guarantees about the ordering of the
operations - you'd never know if thread A or thread B changed it last.

> Can anyone clarify this for me? I'd like to avoid littering my
> threaded code with huge numbers of unnecessary locks...

The above applies to CPython - I'm not too sure about Jython. If you're pretty
familiar with multithreading in other languages and view Python's built-in data
types as fundamental types like integers, then the rules for when to use
locking are pretty much the same as in other languages.

-Dave