Is there a more efficient threading lock?

[Chris Angelico]

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