4 ms·

Not fully. The GIL is always held when executing Python bytecode, because it isn’t threadsafe. Dropping the GIL (parallelism) only happens in native code that e

Not fully. The GIL is always held when executing Python bytecode, because it isn’t threadsafe. Dropping the GIL (parallelism) only happens in native code that explicitly drops it.

chrisseaton 6y ago
> Not fully. This isn't true - they are fully concurrent. The GIL prevents parallelism - not concurrency.
- woadwarrior01 6y ago
  > The GIL prevents parallelism - not concurrency. When a Python thread is holding on to the GIL (running Python bytecode), how many other Python threads can concurrently run in the same process? The answer is zero. Sure the interpreter releases the GIL every n bytecode ops, and C extensions can release the GIL before doing anything IO bound and reacquire it (i.e wait for it) afterwards, but that isn’t full concurrency, in my books.
  - chrisseaton 6y ago
    I think you're describing parallelism. The thread is about concurrency. I think you'll find this definition of concurrency matches industry standard definitions like Padua.
    - woadwarrior01 6y ago
      The broader point is: What good is it if it cannot effectively utilize modern multi-core hardware?
  - mlazos 6y ago
    This is a commonly held misconception. Concurrency actually implies that computations can be reordered without changing the final outcome, and does not imply parallel execution. This is related to parallelism in that concurrent computations can be run in parallel for speed up.
    - deleted 6y ago
      [deleted]
  - mumblemumble 6y ago
    > When a Python thread is holding on to the GIL (running Python bytecode), how many other Python threads can concurrently You've been tricked by jargon. It's a common misconception. In this context, "concurrency" has a specific meaning that is different from the everyday one you're using in this sentence. For a good introduction to what the two words mean in a software engineering context, check out this written version of Rob Pike's talk, "Concurrency is not Parallelism." https://rakhim.org/summary-of-concurrency-is-not-parallellism-a-talk-by-rob-pike/ https://rakhim.org/summary-of-concurrency-is-not-parallellis... The very tl;dr summary is: > Concurrency is composition of independently executing things. . . Parallelism is simultaneous execution of multiple things. When Python's threading model was implemented, parallelism just wasn't much of a concern. CPUs had a single core and could therefore only be working on one thing at a time. (In a macro sense; pipelining and supersclar architectures were still a thing, but not super relevant here.) Multithreading was not a way to do multiple things at once, it was just a way to ensure that some long-running calculation would not cause the program to lock up by, e.g., preventing it form responding to event queues in a timely manner. This was done by, not by running things in parallel, but by switching back and forth among them them very quickly. Python's GIL was designed for this kind of situation. It's there to ensure that nothing bad happens if one of those context switches happens in the middle of a sensitive operation. Which is, strictly speaking, a concurrency concern and not a parallelism concern. (It's also possible to have parallel work that is not concurrent, in which case locks are not necessary. But just because it's common for parallelism and concurrency to co-occur does not mean that they are the same thing.)
- seunosewa 6y ago
  What does fully concurrent mean, exactly? Which commonly used programming languages have threads that are not fully concurrent?
  - chrisseaton 6y ago
    I think it’s binary - it’s either fully concurrent or not concurrent at all.
    - seunosewa 6y ago
      I guess I incorrectly understood “fully concurrent threads” to mean threads that actually run in parallel, like Java threads. The redundant word “fully” threw me off; apologies.

Not fully. The GIL is always held when executing Python bytecode, because it isn’t threadsafe. Dropping the GIL (parallelism) only happens in native code that explicitly drops it.

chrisseaton 6y ago

> Not fully. This isn't true - they are fully concurrent. The GIL prevents parallelism - not concurrency.

woadwarrior01 6y ago
> The GIL prevents parallelism - not concurrency. When a Python thread is holding on to the GIL (running Python bytecode), how many other Python threads can concurrently run in the same process? The answer is zero. Sure the interpreter releases the GIL every n bytecode ops, and C extensions can release the GIL before doing anything IO bound and reacquire it (i.e wait for it) afterwards, but that isn’t full concurrency, in my books.
- chrisseaton 6y ago
  I think you're describing parallelism. The thread is about concurrency. I think you'll find this definition of concurrency matches industry standard definitions like Padua.
  - woadwarrior01 6y ago
    The broader point is: What good is it if it cannot effectively utilize modern multi-core hardware?
- mlazos 6y ago
  This is a commonly held misconception. Concurrency actually implies that computations can be reordered without changing the final outcome, and does not imply parallel execution. This is related to parallelism in that concurrent computations can be run in parallel for speed up.
  - deleted 6y ago
    [deleted]
- mumblemumble 6y ago
  > When a Python thread is holding on to the GIL (running Python bytecode), how many other Python threads can concurrently You've been tricked by jargon. It's a common misconception. In this context, "concurrency" has a specific meaning that is different from the everyday one you're using in this sentence. For a good introduction to what the two words mean in a software engineering context, check out this written version of Rob Pike's talk, "Concurrency is not Parallelism." https://rakhim.org/summary-of-concurrency-is-not-parallellism-a-talk-by-rob-pike/ https://rakhim.org/summary-of-concurrency-is-not-parallellis... The very tl;dr summary is: > Concurrency is composition of independently executing things. . . Parallelism is simultaneous execution of multiple things. When Python's threading model was implemented, parallelism just wasn't much of a concern. CPUs had a single core and could therefore only be working on one thing at a time. (In a macro sense; pipelining and supersclar architectures were still a thing, but not super relevant here.) Multithreading was not a way to do multiple things at once, it was just a way to ensure that some long-running calculation would not cause the program to lock up by, e.g., preventing it form responding to event queues in a timely manner. This was done by, not by running things in parallel, but by switching back and forth among them them very quickly. Python's GIL was designed for this kind of situation. It's there to ensure that nothing bad happens if one of those context switches happens in the middle of a sensitive operation. Which is, strictly speaking, a concurrency concern and not a parallelism concern. (It's also possible to have parallel work that is not concurrent, in which case locks are not necessary. But just because it's common for parallelism and concurrency to co-occur does not mean that they are the same thing.)
seunosewa 6y ago
What does fully concurrent mean, exactly? Which commonly used programming languages have threads that are not fully concurrent?
- chrisseaton 6y ago
  I think it’s binary - it’s either fully concurrent or not concurrent at all.
  - seunosewa 6y ago
    I guess I incorrectly understood “fully concurrent threads” to mean threads that actually run in parallel, like Java threads. The redundant word “fully” threw me off; apologies.