>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
