Martin v. Löwis <martin <at> v.loewis.de> writes: > [gil_drop_request] > 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. 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: http://www.linuxjournal.com/article/8211) As a side note, I remember Jeffrey Yasskin trying to specify an ordering model for Python code (see http://code.google.com/p/unladen-swallow/wiki/MemoryModel). Regards Antoine.
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