On Tue, Aug 27, 2013 at 2:39 AM, Kevin Ballard <[email protected]> wrote: [snip] > My understanding of Python's GIL is that += is indeed atomic because the GIL > only locks/unlocks around statements (though I don't believe this is > intentional). Though this certainly isn't the case for C/C++.
No, that's incorrect. The GIL locks/unlocks around bytecodes, ans ALSO in the middle of C functions (built-in or extension module) if whoever wrote that function thought it might be beneficial. += is compiled into several bytecode ops: First load what you want to add to, then call __iadd__ (assuming it is defined) on it, then storing the result of that (usually the same object) back. The GIL might be released between any of these steps. The last step happens because __iadd__ might not be defined (__add__ is the fallback), but even if that disappeared it still wouldn't be thread-safe. All this is CPython-specific. AFAIK PyPy tries hard to match this behavior, but Jython and IronPython probably give even fewer guarantees. Threading in Python is ugly. In any case, it isn't too relevant for augmented assignment in Rust, for a broad range of reasons. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
