>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4