Is there a more efficient threading lock?
Chris Angelico
rosuav at gmail.com
Sun Feb 26 20:25:28 EST 2023
On Mon, 27 Feb 2023 at 10:42, Jon Ribbens via Python-list
<python-list at python.org> wrote:
>
> On 2023-02-26, Chris Angelico <rosuav at gmail.com> wrote:
> > On Sun, 26 Feb 2023 at 16:16, Jon Ribbens via Python-list
> ><python-list at python.org> wrote:
> >> On 2023-02-25, Paul Rubin <no.email at nospam.invalid> wrote:
> >> > The GIL is an evil thing, but it has been around for so long that most
> >> > of us have gotten used to it, and some user code actually relies on it.
> >> > For example, with the GIL in place, a statement like "x += 1" is always
> >> > atomic, I believe. But, I think it is better to not have any shared
> >> > mutables regardless.
> >>
> >> I think it is the case that x += 1 is atomic but foo.x += 1 is not.
> >> Any replacement for the GIL would have to keep the former at least,
> >> plus the fact that you can do hundreds of things like list.append(foo)
> >> which are all effectively atomic.
> >
> > The GIL is most assuredly *not* an evil thing. If you think it's so
> > evil, go ahead and remove it, because we'll clearly be better off
> > without it, right?
>
> If you say so. I said nothing whatsoever about the GIL being evil.
You didn't, but I was also responding to Paul's description that the
GIL "is an evil thing". Apologies if that wasn't clear.
> Yes, sure, you can make x += 1 not work even single-threaded if you
> make custom types which override basic operations. I'm talking about
> when you're dealing with simple atomic built-in types such as integers.
>
> > Here's the equivalent with just incrementing a global:
> >
> >>>> def thrd():
> > ... x += 1
> > ...
> >>>> dis.dis(thrd)
> > 1 0 RESUME 0
> >
> > 2 2 LOAD_FAST_CHECK 0 (x)
> > 4 LOAD_CONST 1 (1)
> > 6 BINARY_OP 13 (+=)
> > 10 STORE_FAST 0 (x)
> > 12 LOAD_CONST 0 (None)
> > 14 RETURN_VALUE
> >>>>
> >
> > The exact same sequence: load, add, store. Still not atomic.
>
> And yet, it appears that *something* changed between Python 2
> and Python 3 such that it *is* atomic:
I don't think that's a guarantee. You might be unable to make it
break, but that doesn't mean it's dependable.
In any case, it's not the GIL that's doing this. It might be a quirk
of the current implementation of the core evaluation loop, or it might
be something unrelated, but whatever it is, removing the GIL wouldn't
change that; and it's certainly no different whether it's a global or
an attribute of an object.
ChrisA
More information about the Python-list
mailing list