3

I've seen it written many times that the Linux scheduler schedules processes. I'm teaching a course on multithreaded programming, and would like to get my terminology straight. I have one thing I would like to say about it (written below), hoping someone can help me clear out the most egregious errors:

It's not the process that the scheduler schedules, it's the thread associated to that process. The process is simply a bunch of memory mapping segments, and thus static. We can see this clearly when we pthread_create() or even clone() (mostly, but not exactly, the same), whereby one process has several threads, and it is those that are scheduled (otherwise you would only schedule the process thread (the PID=TID one), rather than any other. I assume the ambiguity is due to the fact that all processes have at least one thread of execution.

Is this the correct (although simplified) picture?

Improve this question
4
  • 1
    One thing I've noticed when explaining things to people, is that too much clarification can distract them from the point you're trying to make. I don't have a complete suggestion (so I'm commenting) but you may try being less clear. For example the subordinate clause in your first statement doesn't communicate the information you're interested in conveying, and mentioning individual system calls upfront may cause their notion to get too complicated (learning is incremental after all). I would mention syscalls in a more specific context rather than a general description.
    – Bratchley
    Sep 24, 2013 at 16:20
  • 1
    In fact, I'd probably just describe a process as a collection of one or more threads and the resources (such as memory) associated with that group. "Thread" is conceptually subordinate to "process" anyways (Your wording could be taken to imply they're different but related things). Then mention scheduling as vaguely the operating system's attempt to provide a reasonable order to executing threads/tasks.
    – Bratchley
    Sep 24, 2013 at 16:24
  • @JoelDavis: Thanks! Read my comment to Matt below. I feel the need(!) to be a little bit pedantic with my explanation here, that's why I'm trying to tease out the issue.
    – Dervin Thunk
    Sep 24, 2013 at 20:21
  • It schedules task groups, and then tasks inside those groups stackoverflow.com/questions/12713880/…
    – ninjalj
    Sep 25, 2013 at 10:30

2 Answers 2

Reset to default
6

Try something like this:

All processes start with just one thread, and can create more, using pthread_create for example. (All of a process's threads created this way share the same address space.) The kernel's scheduler works on these threads, regardless of whether they're a process's "main"/initial thread or additional ones - there's essentially no difference between them from scheduler's point of view.

Linux initially didn't have threads at all, only processes. So the part of the OS that schedules "CPU work" is generally called the process scheduler, for historical reasons. (This isn't Linux-specific, same thing for most (all?) Unix-type systems. Thread scheduler is simply not the usual vocabulary used.)

I wouldn't even mention clone (let alone vfork) at that point, unless you've already explained the whole namespaces business.

Improve this answer
1
  • Thanks. This is actually nice. I still need to differentiate between process and thread (that's the whole point of the explanation). Clone needs to be mentioned because that's what pthread_create is, at the core. And the process (address space) must be mentioned because threads share everything (except the stack). I need to be able to draw those distinctions, so i guess I will be a bit more pedantic in the explanation. But I'm happy I was more or less in the right track, thanks!
    – Dervin Thunk
    Sep 24, 2013 at 16:15
1

In Linux kernel, there is no concept of a thread as Linux implements all threads as standard processes.

The Linux kernel does not provide any special scheduling semantics or data structures to represent threads.

Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task_struct and appears to the kernel as a normal process— threads just happen to share resources, such as an address space, with other processes.

To Linux, threads are simply a manner of sharing resources between processes. For example, assume you have a process that consists of four threads. In Linux, there are simply four processes and thus four normal task_struct structures. The four processes are set up to share certain resources.

And as far as kernel threads (that exist solely in kernelspace) are concerned, the only difference between kernel threads and normal processes/threads is that kernel threads do not have an address space. They operate only in kernel-space and do not context switch into user-space.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .