3 ms·

Setting self.__shutdown_request is atomic, assuming it's the default setter implementation. The nogil development uses biased reference counting, with an atomi

Setting self.__shutdown_request is atomic, assuming it's the default setter implementation. The nogil development uses biased reference counting, with an atomic lock between threads, and doesn't change that behavior.

ptx 5y ago
I'm sure there's something I'm missing here, since no-one seems to be talking about it, but how does the nogil version ensure that changes are made visible to other threads, i.e. what Java calls "safely published"? As I understand it, a different thread running on a different core could have a cached version of a value which wouldn't necessarily be updated unless some instruction is issued to synchronize with main memory, which in Java is done with volatile or synchronized. Also, if some optimization is implemented that reorders instructions or eliminates the variable update entirely, that could also prevent the other thread from ever seeing the updated value. This is also solved by using volatile or sychronized in Java. Is every variable implicitly volatile in nogil Python? Or only object attributes? Or have I completely misunderstood some important aspect? Edit: I suppose modifying the reference count might cause implicit synchronization similar to the piggybacking technique [1] in Java, making this a non-issue? [1] https://www.baeldung.com/java-volatile#1-piggybacking https://www.baeldung.com/java-volatile#1-piggybacking
- eesmith 5y ago
  Yes, I believe every variable is implicitly volatile in nogil Python. That said, I am not a good source for truth on this. But it feels like so much code would break if this weren't true that I don't think it would have gotten to this stage. FWIW, here's the primary description of how it works - https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... .

ptx 5y ago

I'm sure there's something I'm missing here, since no-one seems to be talking about it, but how does the nogil version ensure that changes are made visible to other threads, i.e. what Java calls "safely published"? As I understand it, a different thread running on a different core could have a cached version of a value which wouldn't necessarily be updated unless some instruction is issued to synchronize with main memory, which in Java is done with volatile or synchronized. Also, if some optimization is implemented that reorders instructions or eliminates the variable update entirely, that could also prevent the other thread from ever seeing the updated value. This is also solved by using volatile or sychronized in Java. Is every variable implicitly volatile in nogil Python? Or only object attributes? Or have I completely misunderstood some important aspect? Edit: I suppose modifying the reference count might cause implicit synchronization similar to the piggybacking technique [1] in Java, making this a non-issue? [1] https://www.baeldung.com/java-volatile#1-piggybacking https://www.baeldung.com/java-volatile#1-piggybacking

eesmith 5y ago
Yes, I believe every variable is implicitly volatile in nogil Python. That said, I am not a good source for truth on this. But it feels like so much code would break if this weren't true that I don't think it would have gotten to this stage. FWIW, here's the primary description of how it works - https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... .