[Python-Dev] Reworking the GIL

["Martin v. Löwis"]

>> c) is the gil_drop_request handling thread-safe? If your answer is
>>    "yes", you should add a comment as to what the assumptions are of
>>    this code (ISTM that multiple threads may simultaneously attempt
>>    to set the drop request, overlapping with the holding thread actually
>>    dropping the GIL).
> 
> The gil_drop_request is volatile mainly out of precaution, but it's probably not
> necessary. It is only written (set/cleared) when holding the gil_mutex; however,
> it can be read while not holding that mutex. Exceptionally reading the "wrong"
> value would not have any adverse consequences, it would just decrease the
> switching quality at the said instant.

I think it then needs definitely to be volatile - otherwise, the
compiler may chose to cache it in a register (assuming enough registers
are available), instead of re-reading it from memory each time (which is
exactly what volatile then forces it to).

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:

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_10

Of course, on x86, you won't see any issues, because it's cache-coherent
anyway.

Regards,
Martin