K.S.Sreeram <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list