Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><del>Yes, yes it will.</del></p> <p><a href="http://www.techlists.org/archives/programming/pythonlist/2002-03/msg04632.shtml" rel="nofollow noreferrer">I stand corrected</a>.</p> <blockquote> <p>Kragen Sitaker writes:</p> <blockquote> <p>Someone recommended using the idiom</p> <pre><code>spam, eggs = eggs, spam </code></pre> <p>to get a thread-safe swap. Does this really work? (...)<br> So if this thread loses control anywhere between the first LOAD_FAST<br> and the last STORE_FAST, a value could get stored by another thread<br> into "b" which would then be lost. There isn't anything keeping this<br> from happening, is there? </p> </blockquote> <p>Nope. In general not even a simple assignment is necessarily thread safe since performing the assignment may invoke special methods on an object which themselves may require a number of operations. <strong>Hopefully the object will have internally locked its "state" values, but that's not always the case.</strong></p> <p>But it's really dictated by what "thread safety" means in a particular application, because to my mind there are many levels of granularity of such safety so it's hard to talk about "thread safety". About the only thing the Python interpreter is going to give you for free is that a built-in data type should be safe from internal corruption even with native threading. In other words if two threads have <code>a=0xff</code> and <code>a=0xff00</code>, a will end up with one or the other, but not accidentally <code>0xffff</code> as might be possible in some other languages if a isn't protected.</p> <p>With that said, <strong>Python also tends to execute in such a fashion that you can get away with an awful lot without formal locking, if you're willing to live on the edge a bit and have implied dependencies on the actual objects in use</strong>. There was a decent discussion along those lines here in c.l.p a while back - search groups.google.com for the "Critical sections and mutexes" thread among others.</p> <p>Personally, <strong>I explicitly lock shared state</strong> (or use constructs designed for exchanging shared information properly amongst threads, such as <code>Queue.Queue</code>) in any multi-threaded application. To my mind it's the best protection against maintenance and evolution down the road.</p> <p>-- -- <a href="http://www.techlists.org/archives/programming/pythonlist/2002-03/msg04632.shtml" rel="nofollow noreferrer">David</a></p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload