OSDev.org

Hi,

mallard wrote:

Brendan wrote:Except now you've got an additional "process scheduler", and processes continually diddling with their process priority and telling the process scheduler when the process' priority changes.

There's rarely a need to change a process' priority in any system. User-level scheduling doesn't have much of an effect on that. In fact, there's rarely a need to change a thread's priority either. It's usually clear what it should be when the thread is started.

For it to work on single-CPU systems, the process' highest priority "ready to run" thread would determine the process' current priority. It would be constantly changing as threads block and unblock (otherwise "do the most important thing first" fails). For this case you can optimise a little (e.g. if there's 2 high priority threads that are ready to run and one blocks, then the process' priority remains the same), but that's largely ignorable because high priority threads tend to do a small amount of work, so the chance of having 2 or more high priority threads "ready to run" at the same time is almost zero.

For multi-CPU systems, the "process priority" hack no longer works at all.

Let's not forget that almost all the time, a thread blocks because it has to wait for IO, and a thread unblocks because the IO it was waiting for occurred. This means that kernel code (either device drivers for monolithic systems or IPC for micro-kernels) is always involved, so switching to user space for scheduling (instead of doing it in the kernel, while you're already in the kernel to begin with), is completely retarded and saves nothing.

mallard wrote:As with just about everything in programming, there's a trade-off. You gain simplicity in the kernel since you have one "kernel thread" per process and probably improve the speed of (kernel) context switches (since there are less threads to consider).

No, you've still got a scheduler in the kernel. There's little difference between "process scheduler" and "thread scheduler" (it's about the same amount of work).

mallard wrote:You also gain flexibility since userspace processes are free to decide their own scheduling algorithms without affecting anything else.

Processes gain the flexibility to lie to the kernel (e.g. tell the kernel their highest priority thread is "extremely high priority" when it's not) so that its threads can hog CPU time. Yay.

mallard wrote:It can also be faster, as no system call is needed to switch between threads in the same process.

If no system call is involved (whether it's related to IO or caused by priority changes), then there's no point bothering with different threads - just have one thread instead.

mallard wrote:Note that you can have user-level threading even if the OS supports traditional multi-threading. Various programming languages/environments/libraries do so.

Lots of people do lots of silly things for lots of wrong reasons.

mallard wrote:

Brendan wrote:It's a nice example of "additional "something", that makes user level scheduling less efficient and even more pointless".

I know you have (IMHO overly) strong opinions on just about everything related to OS development, but really, most aspects of design are simply a matter of subjective opinion and personal preference. Nobody's forcing you to adopt a particular design. As long as the design is workable, why not just live and let live?

If your sister/daughter/spouse/whatever wanted to try smoking crack and didn't know that it's a bad idea; would you say nothing and laugh while they become a crack addict; or would you try to explain that crack has some disadvantages so that they can make an informed decision?


Cheers,

Brendan

Brendan wrote: If your sister/daughter/spouse/whatever wanted to try smoking crack and didn't know that it's a bad idea; would you say nothing and laugh while they become a crack addict; or would you try to explain that crack has some disadvantages so that they can make an informed decision?

Smoking crack is objectively harmful to the person doing it. OS development (no matter how you do it) is not. In fact, even if you don't get very far or end up giving up on a flawed design, it's generally beneficial; you learn new things, get a better understanding of how other OSs work, etc.

There's absolutely nothing wrong with giving an opinion. Saying "I don't think that's a very good design because..." or "I went with this alternative because..." is fine, good and helpful. However, describing a different idea as "a worthless joke", "pointless", "wrong", etc. isn't at all helpful.

Personally, I would strongly encourage anyone building an OS incorporating new/different ideas. There are plenty of UNIX clones out there (not that building a UNIX clone isn't a major achievement and to be congratulated or that you can't innovate within the confines of "UNIX-like"). Oh, and BTW, UNIX systems traditionally did not allow multiple kernel-level threads per process... That feature didn't begin to appear until around 1990. There's a reason why POSIX.1c allows threads to be entirely user-space. The GNU Portable Threads library is a POSIX.1c-complaint user-level threading library.

Now on to the issue at hand...

Different methods of implementing threads are complex and each have their pros and cons (whether or not you can accept that ways different from yours could possible also be "right").

There are many papers on the subject. User-level threads have the advantage of cheap context switches. Your observation that you could "just have one thread instead" is exactly right. Ultimately, a computer can really only execute one program per CPU core, anything more than that is simply a simulation. The kernel simulates having one CPU core per processes/"kernel thread" and a user-space scheduler than extend this to simulating one CPU core per user-space thread. So, from the kernel's POV you do "just have one thread" just as from the CPU's POV the entire system is "just one thread". Threads/processes are just an abstraction for the programmer.

Processes "lying" to the kernel is possible on any system that lets processes set their own priority. Where it matters (e.g. on a multi-user system) there are usually security measures the mitigate the impact of this (e.g. only specially-privileged users can set priority above a certain level).

I'm still not sure why you'd need to change a process's priority regularly. Why would you have two threads of wildly differing priority in the same process in the first place?

Of course, the big disadvantage to using purely user-level threading is the inability to take advantage of multiple CPUs/cores. However, it's entirely possible (and common) to have both user-level and kernel-level threads available on the same system. This then allows you to choose on a per-thread basis. If you've got two threads that are closely working together (e.g. a producer and consumer) where it's rare that both are simultaneously runnable it can make sense for them to share a single kernel-level thread so that switching between them is fast. In this case, you're effectively using user-level threads to implement coroutines (and if your user-level scheduler is non-preemptive, that's exactly what you've got). If you have multiple threads that are often simultaneously runnable and don't share much data, then having them on separate kernel threads so that they can use different CPU cores, if available.

The world of OS development isn't black-and-white. Trying new/different ideas is a good thing; even if they don't ultimately work out, you've learned something.

Hi,

mallard wrote:I'm still not sure why you'd need to change a process's priority regularly. Why would you have two threads of wildly differing priority in the same process in the first place?

It's all about "do the most important thing first". A process may do many things, some may be part of responding to the user (e.g. handling key presses and mouse clicks, and updating video) that need to be higher priority, some may be background stuff (e.g. spell checking) that should be low priority, some might be "medium priority" (auto-saving every 5 minutes maybe). That's just a simple text editor/word processor though (where you don't want (e.g.) pressing a key to take longer because you happen to be doing spell checking and/or auto-save at the same time). More complex things can benefit from more threads and more priorities.

Sadly (or fortunately, depending on your perspective), a lot of software and a lot of OSs don't do the most important thing first. To see this for yourself, try running Linux on a system with only one CPU. You'll find that (e.g.) the GUI and applications are fine when there's no other load, but become virtually unusable when the OS is doing other things (e.g. compiling) in the background. This is because the OS isn't doing the most important thing (e.g. user key presses and GUI) and is doing less important things (e.g. compiler). Note: The problem isn't as noticeable when there's lots of CPUs because there's a lot higher chance that the scheduler will give CPU time to the application or GUI by accident. It's still bad, just less obvious.

If you do the exact same thing with a better OS (e.g. Windows or BeOS or Haiku or...) you'll find that under the same conditions (same single CPU system, similar applications, similar GUI) you can't tell the difference between "no load" and "lots of load" - the GUI and applications are just as responsive. This is not because the OSs are faster, it's because they're using thread priorities properly. Also note that all applications on BeOS/Haiku are designed with a minimum of 2 threads (one high priority thread for handling keyboard/mouse events, etc; and a lower priority thread for actual work); and this is what makes BeOS/Haiku even more responsive than Windows.

mallard wrote:Of course, the big disadvantage to using purely user-level threading is the inability to take advantage of multiple CPUs/cores. However, it's entirely possible (and common) to have both user-level and kernel-level threads available on the same system. This then allows you to choose on a per-thread basis. If you've got two threads that are closely working together (e.g. a producer and consumer) where it's rare that both are simultaneously runnable it can make sense for them to share a single kernel-level thread so that switching between them is fast. In this case, you're effectively using user-level threads to implement coroutines (and if your user-level scheduler is non-preemptive, that's exactly what you've got). If you have multiple threads that are often simultaneously runnable and don't share much data, then having them on separate kernel threads so that they can use different CPU cores, if available.

The world of OS development isn't black-and-white. Trying new/different ideas is a good thing; even if they don't ultimately work out, you've learned something.

Almost everyone that's done it (and many well known OSs have), realised it sucked and switched to kernel threading. If it isn't black and white, then it's an extremely light shade of grey and a very dark shade of grey.


Cheers,

Brendan