thread-safe swap

David Bolen db3l at fitlinxx.com
Wed Mar 27 17:16:04 EST 2002


Kragen Sitaker <kragen at pobox.com> writes:

> Someone recommended using the idiom
> 
>     spam, eggs = eggs, spam
> 
> to get a thread-safe swap.  Does this really work?
(...)
> So if this thread loses control anywhere between the first LOAD_FAST
> and the last STORE_FAST, a value could get stored by another thread
> into "b" which would then be lost.  There isn't anything keeping this
> from happening, is there?

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.  Hopefully
the object will have internally locked its "state" values, but that's
not always the case.

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 "a=0xff"
and "a=0xff00", a will end up with one or the other, but not
accidentally "0xffff" as might be possible in some other languages if
a isn't protected.

With that said, 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.  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.

Personally, I explicitly lock shared state (or use constructs designed
for exchanging shared information properly amongst threads, such as
Queue.Queue) in any multi-threaded application.  To my mind it's the
best protection against maintenance and evolution down the road.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list