If a workaround like itertools.count.__next__() is used because it will not
be interrupted as it is implemented in C, then I have to ask if it would
make sense for Python to supply something similar in the standard library
for the sole purpose of a use in locks.
But realistically, this is one place the concept of an abstract python
language intersects aspects of what is bundled into a sort of core at or
soon after startup, as well as the reality that python can be implemented in
many ways including some ways on some hardware that may not make guarantees
to behave this way.
Realistically, the history of computing is full of choices made that now
look less useful or obvious.
What would have happened if all processors had been required to have some
low level instruction that effectively did something in an atomic way that
allowed a way for anyone using any language running on that machine a way to
do a simple thing like set a lock or check it?
Of course life has also turned out to be more complex. Some architectures
can now support a small number of operations and implement others as sort of
streams of those operations liked together. You would need to be sure your
program is very directly using the atomic operation directly.
From: Python-list <firstname.lastname@example.org> On
Behalf Of Dieter Maurer
Sent: Wednesday, March 1, 2023 1:43 PM
To: Chris Angelico <email@example.com>
Subject: Look free ID genertion (was: Is there a more efficient threading
Chris Angelico wrote at 2023-3-1 12:58 +1100: > ...
>atomicity would be more useful in that context as it would give
>lock-free ID generation, which doesn't work in Python.
I have seen `itertools.count` for that.
This works because its `__next__` is implemented in "C" and therefore will
not be interrupted by a thread switch.