<p>In modern systems (e.g. Linux for a long time now) what the kernel schedules directly are threads. A process is just a bunch of threads sharing some extra stuff, like memory areas and open files. Way back a couple of experiments were run under Linux on userspace managed threads/hybrid systems/kernelspace managed threads (back when the way to use threads was the userspace pthreads library), and kernel threads won hands down. Solaris used to champion a hybrid model (mostly for herding thousands of Java threads in some applications), and silently migrated to kernel threads</p>

<p>That it is called "process scheduling" is just a remnant from olden times, when there were no threads and everything was processes.</p>

CC BY-SA 4.0
2018-05-18T13:11:02.130Z
2018-05-18T13:11:02.130Z
vonbrand
<p>Perhaps I'm just naive, but I don't see a dilemma here. Yes, teach them the current state of the art if that is appropriate in your course. Teach them some important historical precedents at some appropriate level of detail. In this case you shouldn't be teaching one edition of a book or one version of a particular OS. If the students are to have a future in the field they will still be working in 30-40 or more years. What they need is the background and skill to keep up with technological changes as they occur. </p>

<p>You already say that you teach them the various scheduling algorithms for associating a software element with hardware. That is more essential than the specific granularity of the elements on either side of the equation. Even the standards of what constitutes <em>efficiency</em> may change over time. <em>Teach them the principles</em>, for which some blend of the old and the new is likely required. This will serve them well in matters other than Operating Systems proper. </p>

<p>You should also look at a more recent edition of your text and at other books. This will help you get a handle on what the authors currently consider to be important. Tannenbaum, for example, would be a good supplement to Silberschatz et al. </p>

CC BY-SA 3.0
2018-04-28T17:29:08.563Z
2018-04-28T17:29:08.563Z
Buffy
<p>I have been teaching Operating Systems basics in a class and after Processes, Child Processes and Threads, we have managed to move to "Process Scheduling" </p>

<p>Now, ironically, as we know that it is not the Process which is scheduled, but the threads precisely (we are following Linux Ubuntu there).</p>

<p>Here is what <em>Silberchatz</em> book (<em>by the way, the title of the chapter is also "Process Scheduling"</em>) says about it:</p>

<blockquote>
  <p>In Chapter 4, we introduced threads to the process model. On operating
  systems that support them., it is kernel-level threads-not processes-that are
  in fact being scheduled by the operating system. However, the terms process
  scheduling and thread scheduling are often used interchangeably.</p>
</blockquote>

<p><em>(Silberschatz, Operating System Concepts, 8th Edition)</em></p>

<p>Although, I have taught them the respective algorithms; should I bring this discussion within the class and press the panic button by telling that its not the Processes which are scheduled but Threads? This question has been in my mind since long time and I couldn't look for a better place to get an answer than here.</p>

CC BY-SA 3.0
2018-04-28T14:14:12.137Z
No references,  so this is a comment not an answer. A lot of Tremont in CS is what it is for historical reasons, and not related to the way things really work today. I'd say have the discussion. My seven year old is comfortable with "we cali it X because that's how it used to work,  but it works differently now.". If students in an operating systems course haven't already figured this much out,  they don't belong in the OS course IMHO.
pojo-guy
CC BY-SA 3.0
2018-04-28T17:13:08.673Z
Before the 1990's each process in Unix had only one thread, so they were the same thing. No one had bothered to add threads to Unix, because in Unix: Processes are cheep; `select` works, so event driven is easy; we have a windowing system (that runs in a different process), so no need to have each application manage its own windowing operations in a separate thread.
ctrl-alt-delor
CC BY-SA 3.0
2018-04-28T17:15:15.283Z
Yes tell them, but work it in to a discussion, on the difference between threads and processes.
ctrl-alt-delor
CC BY-SA 3.0
2018-04-29T06:04:45.727Z
Thanks to both of you! Its a good idea to work it in to a discussion on difference between the two.
Failed Scientist
CC BY-SA 4.0
2018-06-21T21:45:50.107Z
The "process" in "process scheduling" is an abstraction. What is called a "thread" in Linux is a process and what is called a "process" in Linux is a process. Just as in Java there are two kinds of variables--"variables" & "objects".
philipxy
<curriculum-design><best-practice>
Process Scheduling is not "Process" Scheduling - Should I disclose it to students?
# Process Scheduling is not "Process" Scheduling - Should I disclose it to students?

(Asked by: username_0 on 2018-04-28)

I have been teaching Operating Systems basics in a class and after Processes, Child Processes and Threads, we have managed to move to "Process Scheduling"

Now, ironically, as we know that it is not the Process which is scheduled, but the threads precisely (we are following Linux Ubuntu there).

Here is what *Silberchatz* book (*by the way, the title of the chapter is also "Process Scheduling"*) says about it:

> In Chapter 4, we introduced threads to the process model. On operating
> systems that support them., it is kernel-level threads-not processes-that are
> in fact being scheduled by the operating system. However, the terms process
> scheduling and thread scheduling are often used interchangeably.

*(Silberschatz, Operating System Concepts, 8th Edition)*

Although, I have taught them the respective algorithms; should I bring this discussion within the class and press the panic button by telling that its not the Processes which are scheduled but Threads? This question has been in my mind since long time and I couldn't look for a better place to get an answer than here.

**Tags:** curriculum-design, best-practice

> **Comments:**
> **username_1**: No references,  so this is a comment not an answer. A lot of Tremont in CS is what it is for historical reasons, and not related to the way things really work today. I'd say have the discussion. My seven year old is comfortable with "we cali it X because that's how it used to work,  but it works differently now.". If students in an operating systems course haven't already figured this much out,  they don't belong in the OS course IMHO.  
> **username_2**: Before the 1990's each process in Unix had only one thread, so they were the same thing. No one had bothered to add threads to Unix, because in Unix: Processes are cheep; `select` works, so event driven is easy; we have a windowing system (that runs in a different process), so no need to have each application manage its own windowing operations in a separate thread.  
> **username_2**: Yes tell them, but work it in to a discussion, on the difference between threads and processes.  
> **username_0**: Thanks to both of you! Its a good idea to work it in to a discussion on difference between the two.  
> **username_3**: The "process" in "process scheduling" is an abstraction. What is called a "thread" in Linux is a process and what is called a "process" in Linux is a process. Just as in Java there are two kinds of variables--"variables" & "objects".  

---

## 2 answers

### Answer by username_5 on 2018-04-28. Score: 3

Perhaps I'm just naive, but I don't see a dilemma here. Yes, teach them the current state of the art if that is appropriate in your course. Teach them some important historical precedents at some appropriate level of detail. In this case you shouldn't be teaching one edition of a book or one version of a particular OS. If the students are to have a future in the field they will still be working in 30-40 or more years. What they need is the background and skill to keep up with technological changes as they occur.

You already say that you teach them the various scheduling algorithms for associating a software element with hardware. That is more essential than the specific granularity of the elements on either side of the equation. Even the standards of what constitutes *efficiency* may change over time. *Teach them the principles*, for which some blend of the old and the new is likely required. This will serve them well in matters other than Operating Systems proper.

You should also look at a more recent edition of your text and at other books. This will help you get a handle on what the authors currently consider to be important. Tannenbaum, for example, would be a good supplement to Silberschatz et al.


---

### Answer by username_4 on 2018-05-18. Score: 2

In modern systems (e.g. Linux for a long time now) what the kernel schedules directly are threads. A process is just a bunch of threads sharing some extra stuff, like memory areas and open files. Way back a couple of experiments were run under Linux on userspace managed threads/hybrid systems/kernelspace managed threads (back when the way to use threads was the userspace pthreads library), and kernel threads won hands down. Solaris used to champion a hybrid model (mostly for herding thousands of Java threads in some applications), and silently migrated to kernel threads

That it is called "process scheduling" is just a remnant from olden times, when there were no threads and everything was processes.


---

