3
$\begingroup$

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.

$\endgroup$
5
  • 2
    $\begingroup$ 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. $\endgroup$
    – pojo-guy
    Commented Apr 28, 2018 at 14:14
  • $\begingroup$ 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. $\endgroup$ Commented Apr 28, 2018 at 17:13
  • 1
    $\begingroup$ Yes tell them, but work it in to a discussion, on the difference between threads and processes. $\endgroup$ Commented Apr 28, 2018 at 17:15
  • $\begingroup$ Thanks to both of you! Its a good idea to work it in to a discussion on difference between the two. $\endgroup$ Commented Apr 29, 2018 at 6:04
  • 1
    $\begingroup$ 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". $\endgroup$
    – philipxy
    Commented Jun 21, 2018 at 21:45

2 Answers 2

3
$\begingroup$

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.

$\endgroup$
0
2
$\begingroup$

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.

$\endgroup$

Your Answer

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

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