4 ms·

But if you're writing to the same object from two different threads you're going to have undefined behavior regardless of the GIL, yes?

NovemberWhiskey 5y ago
Not really. If you're doing an atomic write to the same object from two different threads, you're going to have one win the race and the other lose. That may be a bug in your code, but it's not undefined behavior at the language level.
ajkjk 5y ago
It prevents classes of errors, such as, as the parent mentioned, non-atomic writes to individual variables.
fulafel 5y ago
No. The L in GIL stands for lock. So only the thread that holds it can write or read from the object, and the behavior is well defined at the C level, because C lock acquire and release operations are defined to be memory barriers.
- dkersten 5y ago
  But when each thread reads the variable, you have no control over which value you see, since you don't control when each thread gets to run. So its undefined in the sense that you don't know which values you will get: a thread might get the value it wrote, or the value the other thread wrote. The threads might not get the same value either. The GIL exists to protect the interpreters internal data, not your applications data. If you access mutable data from more than one thread, you still need to your own synchronisation.
  - Thorrez 5y ago
    How is the GIL different from atomics in other languages? There are many cases where atomics are useful. One example would be incrementing a counter for statistics purposes. If the counter is atomic, and the reader of the value is ok with a slightly out of date value, it's fine. If code is doing this in GIL Python, it's working now, and will break after the GIL is removed.
    - dragonwriter 5y ago
      > How is the GIL different from atomics in other languages? Atomics are isolated to where they are needed, the GIL is global though C (but not Python) code can release it.
      - Thorrez 5y ago
        My question was about from a program correctness standpoint, not an efficiency standpoint. But it does look there is a difference from a correctness standpoint, as other comments address.
    - detaro 5y ago
      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.
  - fulafel 5y ago
    I agree that in principle the GIL is there for the interpreter, but in practice in globally ensuring all Python objects are in a coherent and safe state for each running thread, it makes many things quite thread-safe. For example you could use a normal list as a fifo queue, if you were to rely on the current behaviour.
    - dkersten 5y ago
      Sure, but you really need to understand the internals to be able to make these assumptions. For instance, in your example, I know that the call to the C code to do the list operations is atomic (a single bytecode instruction), but I can't assume that all such calls to C code are safe because of this, unless I know for sure that the C code doesn't itself release the GIL. I assume that simple calls like list append/pop wouldn't have any reason to do this, but I can't assume this for any given function/method call that delegates to C, since some calls do release the GIL. So, with or without GIL, you either really need to understand what's going on under the hood so you can avoid using locks in your code (GIL or atomics-based lock-free programming), or you use locks (mutex, semaphore, condition variables etc). No matter what you do, to write thread safe programs, you need to understand what you're doing and how things are synchronizing and operating. The GIL doesn't remove that need. Of course, removing the GIL removes one possible implementation option, I just don't believe the GIL really makes it any easier. Once you know enough internals to know what is and isn't safe with the GIL, you could just as easily do your own syncrhonization.
hexane360 5y ago
It depends what you mean by 'undefined behavior'. The GIL makes operations atomic on the bytecode instruction level. Critically, this includes loading and storing of objects, meaning that refcounting is atomic. However, this doesn't extend to most other operations, which generally need to pull an object onto the stack, manipulate it, and store it back in separate opcodes. So with Python concurrency, you can get unpredictable behavior (such as two threads losing values when incrementing a counter), but not undefined behavior in the C sense, such as use-after-free.

NovemberWhiskey 5y ago

Not really. If you're doing an atomic write to the same object from two different threads, you're going to have one win the race and the other lose. That may be a bug in your code, but it's not undefined behavior at the language level.

ajkjk 5y ago

It prevents classes of errors, such as, as the parent mentioned, non-atomic writes to individual variables.

fulafel 5y ago

No. The L in GIL stands for lock. So only the thread that holds it can write or read from the object, and the behavior is well defined at the C level, because C lock acquire and release operations are defined to be memory barriers.

dkersten 5y ago
But when each thread reads the variable, you have no control over which value you see, since you don't control when each thread gets to run. So its undefined in the sense that you don't know which values you will get: a thread might get the value it wrote, or the value the other thread wrote. The threads might not get the same value either. The GIL exists to protect the interpreters internal data, not your applications data. If you access mutable data from more than one thread, you still need to your own synchronisation.
- Thorrez 5y ago
  How is the GIL different from atomics in other languages? There are many cases where atomics are useful. One example would be incrementing a counter for statistics purposes. If the counter is atomic, and the reader of the value is ok with a slightly out of date value, it's fine. If code is doing this in GIL Python, it's working now, and will break after the GIL is removed.
  - dragonwriter 5y ago
    > How is the GIL different from atomics in other languages? Atomics are isolated to where they are needed, the GIL is global though C (but not Python) code can release it.
    - Thorrez 5y ago
      My question was about from a program correctness standpoint, not an efficiency standpoint. But it does look there is a difference from a correctness standpoint, as other comments address.
  - detaro 5y ago
    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.
- fulafel 5y ago
  I agree that in principle the GIL is there for the interpreter, but in practice in globally ensuring all Python objects are in a coherent and safe state for each running thread, it makes many things quite thread-safe. For example you could use a normal list as a fifo queue, if you were to rely on the current behaviour.
  - dkersten 5y ago
    Sure, but you really need to understand the internals to be able to make these assumptions. For instance, in your example, I know that the call to the C code to do the list operations is atomic (a single bytecode instruction), but I can't assume that all such calls to C code are safe because of this, unless I know for sure that the C code doesn't itself release the GIL. I assume that simple calls like list append/pop wouldn't have any reason to do this, but I can't assume this for any given function/method call that delegates to C, since some calls do release the GIL. So, with or without GIL, you either really need to understand what's going on under the hood so you can avoid using locks in your code (GIL or atomics-based lock-free programming), or you use locks (mutex, semaphore, condition variables etc). No matter what you do, to write thread safe programs, you need to understand what you're doing and how things are synchronizing and operating. The GIL doesn't remove that need. Of course, removing the GIL removes one possible implementation option, I just don't believe the GIL really makes it any easier. Once you know enough internals to know what is and isn't safe with the GIL, you could just as easily do your own syncrhonization.

hexane360 5y ago

It depends what you mean by 'undefined behavior'. The GIL makes operations atomic on the bytecode instruction level. Critically, this includes loading and storing of objects, meaning that refcounting is atomic. However, this doesn't extend to most other operations, which generally need to pull an object onto the stack, manipulate it, and store it back in separate opcodes. So with Python concurrency, you can get unpredictable behavior (such as two threads losing values when incrementing a counter), but not undefined behavior in the C sense, such as use-after-free.