0

I remember from "Linux kernel development" book that for Linux scheduler threads and process are the same (tasks) and when interrupt arrives or thread waits for something to happen scheduler pics another task to execute. I was completely unaware of thread and process context switch until I saw this question. The answer explains in good details costs of each switch, however the idea of having two type of switches is fuzzy for me.

Both types involve handing control over to the operating system

How can virtual memory space remain the same during thread switch if both switches involve handing control over to the operating system? If it remains the same and thread switch is cheaper than process switch then kernel scheduler should somehow prefer tasks which are in same process, right? Does Linux do something like this?

Mher Didaryan
  • 95
  • 2
  • 13
  • I've deleted my comment because it wasn't really accurate. There is **only one** switch. If the next thread is from a different process then memory remapping happens. You may want to read this as well: https://stackoverflow.com/questions/7439608/steps-in-context-switching?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa I don't think threads and processes are distinguished (i.e. preferred one over other) in this process. To be honest I don't think there actually is such thing as process. In the sense that a process is just a group of threads. I'm not an expert though. – freakish Apr 12 '18 at 17:49
  • And going to the kernel space and back does not have to involve any virtual memory manipulation per se. It happens only to maintain isolation (and because of some other reasons, e.g. copy-on-write) between processes (which obviously is not needed when switching inside a process). But that's an addition to the context switch, it's not a property of the switch itself. – freakish Apr 12 '18 at 17:57
  • 1
    Short answer: "handing control over to the operating system" (a.k.a., a _[system call](https://en.wikipedia.org/wiki/System_call#Typical_implementations)_) is not considered to be a _[context switch](https://en.wikipedia.org/wiki/Context_switch)_. It's more akin to an [interrupt](https://en.wikipedia.org/wiki/Interrupt). – Solomon Slow Apr 12 '18 at 18:02
  • Thanks for clarification. Really good point. So we can say that there's one switch in Linux (task switch) and if it happens that upcoming task is in the same process then it's a thread context switch and if not it's a process context switch? – Mher Didaryan Apr 12 '18 at 18:03

0 Answers0