On Apr 6, 3:30 am, "Emanuele D'Arrigo" <man...@gmail.com> wrote: > 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?)
Mostly, but keep in mind that non-Python code can run on a different core at the same time. This could be stuff like I/O or numerical calcuations written in C. > 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? It'll prevent catastrophic consequences such as segfaults, yes. It won't prevent incorrect results, or some other thread changing something under your feet, though. Also, I believe dicts know when they're being iterated over and will raise an exception on any attempt to add or remove a new key, so at worst you might get a value changed under your feet. I would say, therefore, that as long as you are only modifying values, and not adding or removing them, Diez is correct. (Someone more familiar with dict internals might want to verify.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
