1

Recently I've started reading (again) Tanenbaum's 'Modern Operating Systems 4ed' and I am a little stuck in Chapter 2 that discusses processes and threads. Especially I am confused about user-space threads sub-chapter that lists all advantages and disadvantages of them.

Here is a direct quote in favour of user-space threads:

User-level threads also have other advantages. They allow each process to have its own customized scheduling algorithm. For some applications, for example, those with a garbage-collector thread, not having to worry about a thread being stopped at an inconvenient moment is a plus. They also scale better, since kernel threads invariably require some table space and stack space in the kernel, which can be a problem if there are a very large number of threads.

The way I understand it is that every process that is using threads (therefore creates them/destroy) is responsible for implementing scheduling of these threads in order for them to be efficient. Simple round-robin with predefined short time interval for example.

However later in the sub-chapter we get a quote for disadvantages. Here it comes:

Another problem with user-level thread packages is that if a thread starts running, no other thread in that process will ever run unless the first thread voluntarily gives up the CPU. Within a single process, there are no clock interrupts, making it impossible to schedule processes round-robin fashion (taking turns). Unless a thread enters the run-time system of its own free will, the scheduler will never get a chance.

Hmmm, WTF? So in pros-part there it's an advantage to have process' OWN scheduler for threads and here it seems that no matter that there is customised scheduler - it won't work as expected becuase threads are greedy.

My question is: Is it impossible for process' scheduler when using user-space threads to actually schedule threads in equal manner? Or is my English not good enough to grasp a point here.

PS. When reviewing posted question I was suggested to read this - User-level threads for threading. Isn't it right with a statement that Tanenbaum's model was applicable to older systems? The book was released in 2014 so that might be a thing.

Chlebik
  • 646
  • 1
  • 9
  • 27
  • 1
    You **may** create a scheduler for user-level threads. But this scheduler cannot be **preemptive** one and use clock interrupts. That is, in case of user-level threads you are limited to **voluntary** rescheduling only, when the running threads itself could give up CPU to other thread. – Tsyvarev Sep 10 '20 at 08:14
  • Oh boy... a) it's possible for a kernel to use a "single stack per CPU" model (and there are micro-kernels that do this); and it doesn't really matter much if you have tables, etc in user-space or kernel space (it adds up to about the same amount of RAM regardless of where); so 1st paragraph is rubbish. b) A user-space scheduler can use a timer (e.g. the `timer_create()` POSIX function that causes a signal to be delivered to the process); so 2nd paragraph is rubbish. – Brendan Sep 10 '20 at 10:04
  • Yeah, but isn't sending calls to the kernel significantly slower than handling tables within a process in user-space? – Chlebik Sep 10 '20 at 11:09
  • 1
    The elephant in the RAM is that user-scheduled threads cannot respond quickly to I/O completion interrupts. – Martin James Sep 10 '20 at 18:12

1 Answers1

2

The scheduling algorithm is the algorithm that chooses from among the set of runnable threads, which one should run next. This is the part that you can design however you like in your userspace thread system.

The text in the "disadvantage" section is talking about when the scheduling algorithm gets to run, and is saying that with userspace threads you are generally limited to that only happening when the currently running thread voluntarily enters the scheduler.

So the advantage is referring to what happens when the scheduler runs and the disadvantage is referring to when the scheduler gets to run.

caf
  • 233,326
  • 40
  • 323
  • 462