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. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Dieter Maurer Sent: Wednesday, March 1, 2023 1:43 PM To: Chris Angelico <ros...@gmail.com> Cc: python-list@python.org Subject: Look free ID genertion (was: Is there a more efficient threading lock?) Chris Angelico wrote at 2023-3-1 12:58 +1100: > ... > The >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. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
