On Mon, Jun 14, 2010 at 02:28:58PM +0100, Guido Trotter wrote: > This quite a fun one: we know that it doesn't conflicts with checks on > _drained, as assignments are atomic. The only thing it conflicts with is > itself: if SetDrainFlag(True) and SetDrainFlag(False) were to run at the > same time, ideally we wouldn't want the file to say one thing, and the > memory flag to say another. That's why we update the memory flag to the > file's existance value, instead of a boolean: if another run managed to > run between us creating/deleting the file and us updating the boolean, > and has deleted/created the file instead, we'll set up the boolean to > the right value. > > Signed-off-by: Guido Trotter <[email protected]>
I'm not sure we ever reached a sound and solid agreement that assignements without locks are atomic. Remember that x = y might cause y's __del__() method to be called, if y's refcount becomes zero, at which point it's not atomic anymore. IMHO we should stay away from such overoptimizations, because the actual rules change across Python versions, and we rely on the exact current implementation. Now, given the above, I'm happy to be convinced otherwise. Do we have docs? The only thing I find is http://docs.python.org/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe, which doesn't say anything about attribute lookup (self._drained will also require lookup of _drained in self). So I'm in doubt at this point. iustin, hating threading in non-pure languages
