Multi Threading

Depends on	Processes

“Multi-threading” is the term loosely applied both to running multiple threads and multiple processes on a single machine. However it is most usually used when referring to threads which belong to the same program and which cooperate closely; this is more likely to occur at the thread level (within the same process) for simplicity in communication – e.g. using shared variables.

Benefits

Multi-threaded code can offer some significant advantages to the programmer, not least in enabling simpler source code. It can be easier to decompose a problem into semi-independent units which operate in their own way in their own time than to try to do all the required jobs with a single slab of code. This is often because the timing of functions is unpredictable so writing them in a simple sequence may not match the most efficient order in which they could be scheduled.

Such parallel code, with unpredictable timing, is sometimes referred to as “asynchronous” code. Written as multiple threads, it becomes the thread scheduler’s job to keep the processor(s) busy.

Example: consider a web-server which may take variable times to fetch or construct web pages as demanded; some of the time any request will be waiting for disk access; many requests for pages may arrive closely spaced in time. In this model it may make sense to create a thread for each request which services (just) that as a sequence of operations whilst other threads do similar things for other requests. The application does not need to care that other threads may want to overtake.

Another advantage of multi-threading is that processors are no longer getting much faster but, instead, proliferating in number. A typical workstation “CPU” may have six “cores” – complete processors – today (2022) but that number is set to increase. A small number of processors may be employed running completely independent processes but to keep a large number of cores usefully busy is going to require multi-threaded applications. Thus, threading the code will lead to higher performance.

Specialist processors, such as Graphics Processing Units (GPUs), may already have 1000+ processors although these may not all be completely independent and share the same thread context.

Example: some ‘general purpose’ processors are coming to rival this scale, partly by relying on independent cores and partly by “hyper-threading” within a core. For example, the (at time of writing) latest “SPARC M8” (2017) has 32 processor cores, each with up to 8 threads (that’s up to 256 concurrent threads).

Another example: Intel Xeon Phi chips includes ~60 processor cores, each capable of supporting four threads simultaneously.

Drawbacks

The biggest drawback to multithreading is that it is more difficult to program this way. ‘Traditional’ programming tends to be putting operations into a sequence; when operations are deliberately allowed to happen in an unpredictable order people can get confused. This, in turn, can lead to subtle faults, which only evidence intermittently, making debugging difficult.

It is necessary to ensure that all dependencies in the code are guaranteed; i.e. it is certain that one thread has reached a particular point (e.g. the disk has provided the data) before another thread continues past a point of its own. On the other hand two (or more) threads must not act in a way where they will stop each other from proceeding – a condition known as “deadlock”.

These issues have been common in multiprocessing operating systems for a long time and are becoming increasingly important in applications programming.

That, in itself, is a Good Reason for studying this topic.

---

Also refer to:	Operating System Concepts, 10th Edition: Chapter 4, pages 159-197

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Deadlock

Atomicity • Deadlock • File Locking • Locks • Multi Threading • Multiprocessors • Mutual exclusion • Operation Ordering • Race Conditions • Reentrancy • Semaphores • Starvation • Threads

Articles on Processes

About this resource • Atomicity • Containers • Context • Context Switching • Daemons • Fork Unix • Hypervisor • Idle • Interprocess Communication • Multi Threading • Mutual exclusion • Pipes • Pointer Arithmetic • Process Control Block (PCB) • Process Priority • Process Scheduling • Process States • Processes • Queues • Queues Extra • Race Conditions • Real Time • Resources • Scheduler • Signal and Wait • Sleep • Starvation • Synchronisation • Thrashing • Threads • Unix Signals