9

I've been playing with the Linux kernel recently and diving back into the days of OS courses from college.

Just like back then, I'm playing around with threads and the like. All this time I had been assuming that threads were automatically running concurrently on multiple cores but I've recently discovered that you actually have to explicitly code for handling multiple cores.

So what's the point of multi-threading on a single core? The only example I can think of is from college when writing a client/server program but that seems like a weak point.

8protons
  • 3,155
  • 2
  • 26
  • 57
  • 1
    An operating system that can only run one program at a time is not very popular. – Hans Passant May 14 '16 at 12:24
  • 2
    Only multi-threading can give you the experience of multi-tasking where multiple threads from multiple processes get CPU slices in round robin fashion. Of course at any give point of time only one thread can execute in a single core CPU but round-robin algorithm gives user an experience that they are able to execute multiple programs like checking their email and working on word processor simultaneously. All this is courtesy of context switching concept supported by OS. – RBT May 14 '16 at 12:49

4 Answers4

25

All this time I had been assuming that threads were automatically running concurrently on multiple cores but I've recently discovered that you actually have to explicitly code for handling multiple cores.

The above is incorrect for any widely used, modern OS. All of Linux's schedulers, for example, will automatically schedule threads on different cores and even automatically move threads from one core to another when necessary to maximize core usage. There are some APIs that allow you to modify the schedulers' behavior, but these APIs are generally used to disable automatic thread-to-core scheduling, not to enable it.

So what's the point of multi-threading on a single core?

Imagine you have a GUI program whose purpose is to execute an expensive computation (for example, render a 3D image or a Mandelbrot set) and then display the result. Let's say this computation takes 30 seconds to complete on this particular CPU. If you implement that program the obvious way, and use only a single thread, then the user's GUI controls will be unresponsive for 30 seconds while the calculation is executing -- the user will be unable to do anything with your program, and possibly unable to do anything with his computer at all. Since users expect GUI controls to be responsive at all times, that would be a poor user experience.

If you implement that program with two threads (one GUI thread and one rendering thread), on the other hand, the user will be able to click buttons, resize the window, quit the program, choose menu items, etc, even while the computation is executing, because the OS is able to wake up the GUI thread and allow it to handle mouse/keyboard events when necessary.

Of course, it is possible to write this program with a single thread and keep its GUI responsive, by writing your single thread to do just a few milliseconds worth of computation, then check to see if there are GUI events available to process, handling them, then going back to do a bit more computation, etc. But if you code your app this way, you are essentially writing your own (very primitive) thread scheduler inside your app anyway, so why reinvent the wheel?

The first versions of MacOS were designed to run on a single core, but had no real concept of multithreading. This forced every application developer to correctly implement some manual thread management -- even if their app did not have any extended computations, they had to explicitly indicate when they were done using the CPU, e.g. by calling WaitNextEvent. This lack of multithreading made early (pre-MacOS-X) versions of MacOS famously unreliable at multitasking, since just one poorly written application could bring the whole computer to a grinding halt.

Jeremy Friesner
  • 63,706
  • 14
  • 113
  • 212
  • 1
    A potential alternative to polling or multithreading might be to use something like signal handlers. In addition, with only blocking I/O — not all OSes have always supported asynchronous I/O — something like a file read will pause the entire program even if it has other work independent of the file data. Also one **difference** between single-core multithreading and concurrent multithreading is memory consistency. A single core is sequentially consistent and I suspect most OSes provide sequential consistency for core migration; most ISAs do not guarantee sequential consistency. – Paul A. Clayton May 14 '16 at 17:08
  • In addition, ordinary read-modify-write instructions like an addition that updates memory are atomic with respect to interrupts. Without concurrency, this is sufficient to provide atomicity; with concurrency one would have to add a LOCK prefix which substantially increases the cost of the operation. – Paul A. Clayton May 14 '16 at 17:11
2

First, a program not only computes, but also waits for input/output and so can be considered as executing on an I/O processor. So even single-core machine is a multi-processor machine, and employing of multi-threading is justified.

Second, a task can be divided in several threads in the sake of modularity.

Alexei Kaigorodov
  • 12,853
  • 1
  • 19
  • 36
2

Multithreading is not only for taking advantage of multiple cores.

You need multiple processes for multitasking. For similar reason you are allowed to have multiple threads, which are lightweight compared with processes.

You probably don't want to spawn processes all the time for things like blocking I/O. That may be overkill.

And there is fiber, which is even more lightweight. So we have process, thread, and fiber for different levels of needs.

cshu
  • 5,254
  • 26
  • 39
  • You can have multitasking without multiple processes. For example, AmigaDOS did multitasking very well without any concept of processes at all -- all programs ran in a single address space. (this did mean that any buggy process could and often did take down the entire OS with it when it crashed, but that was viewed as additional incentive to debug your programs before shipping them ;) ) – Jeremy Friesner Aug 21 '17 at 04:44
1

Well, when you say multithreading on a single core, there are things you need to consider. For example, the thread API that you are using - is it user level or kernel level. Most probably from you question I believe you are using user level threads. Now, user level threads, depending upon the host OS or the API itself may map to single kernel thread or multiple. Many relations are possible like 1-1,many-1 or many-many. Now, if there is a single core, your OS can still provide you several Kernel level threads which may behave as multiple processes to the CPU. In which case, OS will give you a time-slicing (and multi-programming) on the kernel threads leading to superfast context switch and via the user level API - you/your code will seem to have multithreaded features. Also note that eventhough your processor is a single core, depending on the make, it can be hyperthreaded and have super deep pipelines allowing the concurrent running of Kernel threads with very low overhead. For references: Check Intel/AMD architecture and how various OS provide Kernel threads.

Snigdhadeb Mukherjee
  • 21
  • 3