How to go about. On read/write locks

[Carl Banks]

On Apr 6, 3:30 am, "Emanuele D'Arrigo" <man... at 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