3 ms·

What atomic counter increment exists currently and would be broken by this proposal?

• Thorrez 5y ago
  Hmm, so even though an increment on a loaded int is atomic, loading it and storing it aren't. https://stackoverflow.com/a/1717514 https://stackoverflow.com/a/1717514 The Python documentation seems misleading to me on this: > In theory, this means an exact accounting requires an exact understanding of the PVM bytecode implementation. In practice, it means that operations on shared variables of built-in data types (ints, lists, dicts, etc) that “look atomic” really are. count = 0 def inc(): count += 1 sure "looks atomic" to me, so according to the documentation should be, but isn't. On the other hand, I think you could build a horribly inefficient actual atomic counter with count = [] def inc(): count.append(None) def get_count(): return len(count) I think it's quite likely there's correct and non-horrible code relying on list append and length being atomic. Although it sounds like this might continue working without the GIL: > A lot of work has gone into the list and dict implementations to make them thread-safe. And so on. So removing the GIL might not be a problem.
  • detaro 5y ago
    Indeed, the proposal explicitly covers maintaining existing guarantees, which is why I was confused that so many people just assumed it would break them.