What is Multithreading?
Multithreading is the way a program makes use of the computer’s processor in order to gain performance improvements, these performance improvements come in the shape of what’s called Concurrent Processing. Concurrent Processing is when tasks are being handled by a processor in a loop, where instead of those tasks being entire programs, they can be sub-tasks which are called Threads.
When a programmer writes a program and executes it, the program’s code and metadata are given their own memory space by the operating system, furthermore, the program is now called a Process. Processes are operating system jobs that stay in a Job Pool while they wait for execution by the computer’s processor, Multi-Core processors can execute multiple jobs simultaneously because they have multiple cores, the cores on a Multi-Core processor are like lanes on a highway, the more cores you have, the more you can do in parallel at any given time, this parallelism is called Parallel Processing and is different from Concurrent Processing.
Concurrent Processing is when a processor core is rapidly switching back and forth between two threads of execution, due to the speed involved, it would appear to the user as though the computer is doing two things in parallel, on the other hand, Parallel Processing is when we extend the power of Concurrent Processing by adding more cores to the processor, in this way, since each core can work independently, we can achieve actual parallelism. Parallel Processing is also possible in computers with multiple processors.
The CPU or processor in a computer deals with Threads of execution, simply called Threads. Threads can be one of two types: User-level Threads and Kernel-level Threads, User-level Threads are created and managed on the user level via a thread library, programmers use these libraries to implement thread functionality into their programs, Kernel-level Threads on the other hand are created and managed by the operating system’s kernel, hence the name.
Processes are single-threaded by default, meaning they can only run one task at a time, but multi-threaded processes can run multiple tasks concurrently. When a process leaves the Job Pool it is offered Kernel-level Threads by the kernel, the User-level Threads of a process take turns on their Kernel-level Threads while the Kernel-level Threads take turns on CPU cores, it is because of this that Kernel-level Threads are also called Virtual Processors. User Threads are mapped to Kernel Threads via 3 different models: The one-to-one model in which exactly one User Thread is mapped to exactly one Kernel Thread. The many-to-one model in which many User Threads are mapped to exactly one Kernel Thread. And the many-to-many model in which many User Threads are mapped to many Kernel Threads.
In the one-to-one model, User Threads of a process can continue execution even if one of them issues a Blocking Call such as reading from a file, and that is because each User Thread is mapped to its own Kernel Thread. In the many-to-one model, when a User Thread issues a Blocking Call, the others are forced to wait, and that is because they are all mapped to the same Kernel Thread. Lastly, the many-to-many model is the most efficient of the three, if a User Thread issues a Blocking Call, the others are unaffected, and thus, continue execution by taking turns on the other Kernel Threads that are not blocked.
This mapping between User and Kernel Threads is necessary for process execution because the operating system is only aware of Kernel Threads, Kernel Threads are what the processor ultimately executes.
Process threads share memory between them, it is for this reason that they are better candidates for Concurrent Programming than creating multiple processes of the same application. Processes do not share memory, furthermore, processes are heavier than threads, Inter-Process Communication is possible, but is slower and trickier than Inter-thread Communication. It’s also worth noting here that when I say that process threads share the same memory, I mean the same memory space as their root process, process threads cannot access memory spaces of other processes.
Data Races and Race Conditions are two pitfalls to avoid when designing Multithreaded code. A Data Race bug occurs when two Threads of a process access a shared memory location concurrently, if one of the threads writes to a memory location while another is reading from it, the data becomes corrupted and that is called a Data Race problem. When two threads of a process are supposed to access a memory location in a specified order, it is possible that that order will be reversed, in this case, we are talking about a Race Condition problem.
Synchronization, and immutable data are two ways of achieving Concurrency Control, synchronizing threads means applying mutual exclusion in shared memory access, in this way, threads aquire locks and release them after they finish modifying a certain memory location, in other words, only one thread can access the location at a time. Immutable data is data that can’t be modified, making data immutable in a shared memory makes concurrency safer since threads can only read from that location, and can’t write to it. There is another method of Concurrency Control, which is the usage of Atomic Instructions, Atomic Instructions are either executed fully by the processor, or not executed at all, because of this, they are Thread-safe by nature, high level languages are non-atomic, a variable assignment for example can be divided into atleast 2 atomic steps: fetch variable x. Write 1 to x, if thread A is doing the assignment, it can be interrupted halfway by another thread B that will for example write 2 to x, then thread A will come back and complete its operation by writing 1 to x, if this is a counting program, then it clearly failed. Having each thread handle 1 single atomic operation would fix the problem.
Multithreading increases the efficiency of a program, however, not every program has to be multithreaded.
