How to go about. On read/write locks

[Emanuele D'Arrigo]

On Apr 6, 7:49 am, "Diez B. Roggisch" <de... at 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