[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(). -- http://mail.python.org/mailman/listinfo/python-list
