Is there a more efficient threading lock?
Jon Ribbens
jon+usenet at unequivocal.eu
Sat Feb 25 18:45:36 EST 2023
On 2023-02-25, Paul Rubin <no.email at nospam.invalid> wrote:
> Jon Ribbens <jon+usenet at unequivocal.eu> writes:
>>> 1) you generally want to use RLock rather than Lock
>> Why?
>
> So that a thread that tries to acquire it twice doesn't block itself,
> etc. Look at the threading lib docs for more info.
Yes, I know what the docs say, I was asking why you were making the
statement above. I haven't used Lock very often, but I've literally
never once in 25 years needed to use RLock. As you say, it's best
to keep the lock-protected code brief, so it's usually pretty
obvious that the code can't be re-entered.
>> What does this mean? Are you saying the GIL has been removed?
>
> Last I heard there was an experimental version of CPython with the GIL
> removed. It is supposed to take less of a performance hit due to
> INCREF/DECREF than an earlier attempt some years back. I don't know its
> current status.
>
> 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.
More information about the Python-list
mailing list