0
$\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?

New contributor
OneRaynyDay is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$
1
$\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.

$\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$ Nov 24 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 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 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$ Nov 25 at 21:10

Your Answer

OneRaynyDay is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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