multithreading and shared dictionary

[Alex Martelli]

K.S.Sreeram <sreeram at tachyontech.net> wrote:
   ...
> Consider two threads A and B, which are independent except for the fact
> that they reside in the same module.
> 
> def thread_A() :
>     global foo
>     foo = 1
> 
> def thread_B() :
>     global bar
>     bar = 2
> 
> These threads create entries in the same module's dict, and they *might*
> execute at the same time. Requiring a lock in this case is very
> non-intuitive, and my conclusion is that dict get/set operations are
> indeed atomic (thanks to the GIL).

Well then, feel free to code under such assumptions (as long as you're
not working on any project in which I have any say:-) -- depending on
subtle (and entirely version-dependent) considerations connected to
string interning, dict size, etc, you _might_ never run into failing
cases (as long as, say, every key in play is a short internable string
[never an instance of a _subtype_ of str of course], every value an int
small enough to be kept immortally in the global small-ints cache, etc,
etc)... why, dicts that forever remain below N entries for sufficiently
small (and version-dependent) N may in fact never be resized at all.

Most of us prefer to write code that will keep working a bit more
robustly (e.g. when the Python interpreter is upgraded from 2.5 to 2.6,
which might change some of these internal implementation details), and
relying on subtle reasoning about what might be "very non-intuitive" is
definitely counterproductive; alas, testing is not a great way to
discover "race conditions", deadlocks, etc, so threading-related errors
must be avoided ``beforehand'', by taking a very conservative stance
towards what operations might or might not happen to be
atomic/threadsafe unless specifically guaranteed by the Language
Reference (or the specific bits of the Library Reference).


Alex