Is += on strings a thread-safe operation?
Stefan Franke
to a string buffer (or other sequences) with += would be a big advantage of the somewhat infamous
augmented assignment operators in my eyes.
Stefan
Stefan Franke
www.meso.net
Aahz Maruch
Stefan Franke <spamf...@bigfoot.de> wrote:
>
>What about augmented assignments of other built-in types? Being able
>to thread-safely append to a string buffer (or other sequences) with +=
>would be a big advantage of the somewhat infamous augmented assignment
>operators in my eyes.
Using the dis module, we see that the only difference between "x+='b'"
and "x=x+'b'" lies in substituting INPLACE_ADD for BINARY_ADD. If the
latter is thread-safe, so is the former; I'm not entirely confident
enough in my byte-code skills to make an assertion. But it looks to me
that it's not thread-safe because you're reading and assigning the same
variable in the same statement.
I *do* know that x.append('b') is a thread-safe operation -- and that's
probably a better bet, anyway, even if threading isn't involved.
--
--- Aahz (Copyright 2001 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
Nostalgia just ain't what it used to be
Warren Postma
"Stefan Franke" <spamf...@bigfoot.de> wrote in message
news:3a9d383...@news.btx.dtag.de...
> What about augmented assignments of other built-in types? Being able to
thread-safely append
> to a string buffer (or other sequences) with += would be a big advantage
of the somewhat infamous
> augmented assignment operators in my eyes.
>
> Stefan
The sad truth is that everything in Python is thread safe, because
ironically, nothing in python is thread safe.
What I mean to say is that when Threading support is enabled in Python,
which on most systems it now is, everything the Python interpreter runs
occurs while it is holding onto a Global Interpreter Lock which is only
released explicitly when it is safe to do so.
So that means in effect that all Python Bytecode operations are explicitly
atomic, thus all Python builtin C functions are atomic, except those which
choose not to be (such as time.sleep()) by letting go of and then
re-acquiring the global interpreter lock. It is not possible for the
interpreter to let go of that lock while in the middle of a string "+=".
In other words, anything that resolves to a single bytecode in Python
interpreter is done while the current thread holds the lock. That makes
invocation of any builtin C function atomic as far as I can see.
Am I right? Where is Timbot when you really need him? <grin>
Warren
Tim Peters
of thread-safety as follows from the global interpreter lock, but
falls for a flawed example]
> ...
> So that means in effect that all Python Bytecode operations are explicitly
> atomic, thus all Python builtin C functions are atomic, except those which
> choose not to be (such as time.sleep()) by letting go of and then
> re-acquiring the global interpreter lock. It is not possible for the
> interpreter to let go of that lock while in the middle of a string "+=".
There's the rub: += generates more than one bytecode, so there actually are
chances for the interpreter to let go of the GIL "in the middle" of *any* +=
(and for multiple spellings of "+=").
> In other words, anything that resolves to a single bytecode in Python
> interpreter is done while the current thread holds the lock.
Yes.
> That makes invocation of any builtin C function atomic as far as
> I can see.
Your eyes are fine -- at least for long-term viewing <wink>.
> Am I right? Where is Timbot when you really need him? <grin>
I only show up when I'm not really needed -- like here.
it's-too-stressful-to-take-a-stand-when-i-am-needed-ly y'rs - tim