On Apr 6, 7:49 am, "Diez B. Roggisch" <de...@nospam.web.de> wrote: > The CPython-specific answer is that the GIL takes care of that for you > right now anyway. So unless you plan for a distant future where some > kind of swallows fly around that don't have a GIL, you are safe to > simply read and write in threads without any locking whatsoever.
Diez, thanks for your reply. I didn't know what the GIL is. I did some research finding an interesting article that did clarify many multi- threading related concepts and issues: http://jessenoller.com/2009/02/01/python-threads-and-the-global-interpreter-lock/ Python's approach with the GIL is both reasonable and disappointing. Reasonable because I understand how it can make things easier for its internals. Disappointing because it means that standard python cannot take advantage of the parallelism that can more and more often be afforded by today's computers. I.e. I found only recently, almost by chance, that my wife's laptop has not one but two processors, even though it isn't a particularly high-end computer. I now understand that OS-level threading does use them both, but I understand that the GIL effectively prevents parallel operations. (Am I understanding correctly?) I do not completely understand your statement in the context of my original example though, the shared dictionary. As the GIL is released every X bytecode operations surely it can happen that as the dictionary is iterated through, i.e. in a for/in loop, a different thread might change it, with potentially catastrophic consequences. The GIL wouldn't be able to prevent this, wouldn't it? Manu -- http://mail.python.org/mailman/listinfo/python-list
