1
$\begingroup$

I was surprised to hear that the threading module from python uses OS level threads. From what I know, OS level threads are more expensive (but can achieve parallelism) meanwhile green threads are user-level, more lightweight, but can only achieve concurrency but not parallelism. Why doesn't the python virtual machine implement a scheduler for user-level threads and replace the threading module OS threads?

If the GIL restricts the number of threads running at once then there is effectively no benefit (other than simplicity of implementation on python's side) to having OS level threads over user level threads, right?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
2
$\begingroup$

Green threads are ancient stuff and the references you are reading are probably citing reasons that mostly don't apply today. It is more complex than you write, with software engineering and performance tradeoffs that are hard to summarize in just a few sentences, but here is a rough overview:

OS level threads allow taking advantage of multiple cores or multiple processors, which are common today.

Green threads incur an overhead to keep track of the thread states and swap between them. If you only have a limited number of threads, the OS is just as good at that or better.

Green threads handle blocking system calls poorly.

Green threads only have the potential to be better if the number of active threads is significantly more than the number of cores/processors. That is not the case for most applications today; for most applications, the number of threads is fewer than the number of cores. Even if it true, there is no guarantee that green threads will be faster; that depends on other factors.

Improve this answer
$\endgroup$
4
  • $\begingroup$ can you explain why green threads handle blocking system calls poorly? I understand that os threads in iowait are not going to be scheduled. Why can't the python virtual machine take care of this in a similar manner? Regarding overhead to keep thread states - doesn't the OS also need to keep track of that as well if we're talking about OS threads? $\endgroup$
    – OneRaynyDay
    Nov 24, 2021 at 19:32
  • $\begingroup$ @OneRaynyDay, I'm sure if you do some research you'll be able to learn more. If one green thread does a blocking system call, that will block many other green threads (all of the green threads that are assigned to the same OS thread). If that's not enough, I suggest doing some research, then asking a new question about that aspect specifically, and show your research and your current understanding. I don't know what "similar manner" means. Note that questions that are focused only on the Python VM might be treated by the community as off-topic here. $\endgroup$
    – D.W. ♦
    Nov 24, 2021 at 19:59
  • $\begingroup$ @OneRaynyDay, regarding overhead, yes, the OS will also have overhead, but as I wrote in my answer, "If you only have a limited number of threads, the OS is just as good at that or better". $\endgroup$
    – D.W. ♦
    Nov 24, 2021 at 20:00
  • $\begingroup$ The BEAM VM is a great example of your last paragraph: Erlang programs can have thousands or even millions of threads (actually processes), so the fact that BEAM processes only weigh ~300 bytes compared to e.g. Windows threads at 12 kilobytes is important. (Erlang uses processes much like OO languages use objects.) $\endgroup$
    – Jörg W Mittag
    Nov 25, 2021 at 21:10
0
$\begingroup$

It's not necessarily true that green threads cannot achieve parallelism. Just check out the runtimes for Go, Elixir, and Clojure - they're doing just fine.

While the actual reason as to why Python didn't go for this route is unclear, if I had to guess: it's probably because green threads don't play nice with C.

Python has a closer relation to C than most languages that have their reference implementations written in C. You'll find that many Python primitives map directly to the underlying C implementation. Interfacing with C code from Python already has many costs, having green threads just means appending the extra cost of context switches to that list. So, it should make sense that Python uses OS threads, because C does the same.

Python has many target audiences. While web developers might benefit from getting the same experience in Python as they get in a language like Go, something like this might've broken the scientific community's heart in other, unexpected ways.

That said, the future looks promising in 2022: CPython is getting rid of the GIL, and Python has a better WASM story than most people expected. I'm not sure where my stance will be in the future, but for now, I'd probably use a better language for the job.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.