dictionaries and threads

[Tim Peters]

[Gary Robinson]
> I know the Global Interpreter Lock ensures that  only one python thread
> has access to the interpreter at a time, which prevents a lot of
> situations where one thread might step on another's toes.

Not really.  The CPython implementation's C code relies on the GIL in
many ways to provide mutual exclusion, but there's no such effect at
the Python level: operations from multiple Python threads can get
interleaved in any order consistent with sequential execution within
each thread.  The guarantee that the builtin datatypes provide "not to
go insane" in the absence of application synchronization is really a
separate matter, _aided_ in CPython by the GIL, but not guaranteed by
the GIL alone.  There's still an enormous amount of delicate fiddling
in Python's C code to keep internals sane in the absence of
application locking.

> But I'd like to ask about a specific situation just to be sure  I
> understand things relative to some code I'm writing.
>
> I've got a dictionary which is accessed by several threads at the same
> time (that is, to the extent that the GIL allows). The thing is,
> however, no two threads will ever be accessing the same dictionary
> items at the same time. In fact the thread's ID from thread.get_ident()
> is the key to the dictionary; a thread only modifies items
> corresponding to its own thread ID. A thread will be adding an item
> with its ID when it's created, and deleting it before it exits, and
> modifying the item's value in the meantime.
>
> As far as I can tell, if the Python bytecodes that cause dictionary
> modifications are atomic, then there should be no problem. But I don't
> know that they  are because I haven't looked at the bytecodes.

It's unclear what kind of problem you're concerned about.  The kind of
dict you described is widely used in Python apps; for example, it's at
the heart of the implementation of threading.currentThread() in the
standard library.  That dicts promise not to go insane in the absence
of locking isn't a GIL issue, even if multiple threads do modify d[k]
simultaneously (in the absence of app locking, all such threads will
eventually change d[k], but in an undefined order; if no two threads
can muck with the same k, there's no problem at all).

> Any feedback on this would be appreciated. For various reasons, we're
> still using Python 2.3 for the time being.

Best practice in 2.3 is to subclass threading.Thread for all threads
you use.  Then instead of mucking with a dict, you can just
set/retrieve an attribute on the current Thread object.  You can get
the currently active Thread at any time via calling
threading.currentThread().