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_0... Of course, on x86, you won't see any issues, because it's cache-coherent anyway. Regards, Martin