[Python-Dev] Reworking the GIL
solipsis at pitrou.net
Mon Nov 2 13:15:28 CET 2009
Martin v. Löwis <martin <at> v.loewis.de> writes:
> Even if it is read from memory, I still wonder what might happen on
> systems that require explicit memory barriers to synchronize across
> CPUs. What if CPU 1 keeps reading a 0 value out of its cache, even
> though CPU 1 has written an 1 value a long time ago?
> IIUC, any (most?) pthread calls would cause synchronization in that
> case, which is why applications that also use locks for reading:
> Of course, on x86, you won't see any issues, because it's cache-coherent
I think there are two things here:
- all machines Python runs on should AFAIK be cache-coherent: CPUs synchronize
their views of memory in a rather timely fashion.
- memory ordering: writes made by a CPU can be seen in a different order by
another CPU (i.e. CPU 1 writes A before B, but CPU 2 sees B written before A). I
don't see how this can apply to gil_drop_request, since it's a single variable
(and, moreover, only a single bit of it is significant).
(there's an explanation of memory ordering issues here:
As a side note, I remember Jeffrey Yasskin trying to specify an ordering model
for Python code
More information about the Python-Dev