4 ms·

> 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 co

> 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.)

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.)