What Are The Thread Registers

Threads

Multiple flows of execution within a procedure

February 5, 2014

Introduction

When we looked at the concept of the procedure, we considered the stardom between a plan and process. A process was a programme in memory along with dynamically-allocated storage (the heap), the stack, and the execution context, which comprises the state of the processor's registers and education pointer (plan counter).

If nosotros take a closer await at the procedure, we can break it into ii components:

The program and dynamically allocated memory.
The stack, instruction arrow, and registers.

The second item is crucial for the execution flow of the program. The instruction pointer keeps track of which instructions to execute side by side, and those instructions bear upon the registers. Subroutine call/render instructions as well instructions that button or pop registers on the stack on entry to or get out from a function call adjust the contents of the stack and the stack pointer. This stream of instructions is the process' thread of execution.

A traditional process has one thread of execution. The operating organisation keeps track of the retentivity map, saved registers, and stack pointer in the process command block and the operating arrangement's scheduler is responsible for making sure that the process gets to run every one time in a while.

Multithreading

Memory map with two threads — Retentivity map with ii threads

A process may exist multithreaded, where the same plan contains multiple concurrent threads of execution. An operating system that supports multithreading has a scheduler that is responsible for preempting and scheduling all threads of all processes.

In a multi-threaded process, all of the procedure' threads share the same memory and open files. Inside the shared retention, each thread gets its own stack. Each thread has its own pedagogy pointer and registers. Since the memory is shared, it is important to note that in that location is no memory protection amid the threads in a process.

An operating system had to continue track of processes, and stored its per-process information in a information structure chosen a process control block (PCB). A multithread-aware operating organisation likewise needs to keep track of threads. The items that the operating organization must store that are unique to each thread are:

Thread ID
Saved registers, stack arrow, instruction arrow
Stack (local variables, temporary variables, return addresses)
Signal mask
Priority (scheduling data)

The items that are shared among threads within a process are:

Text segment (instructions)
Information segment (static and global data)
BSS segment (uninitialized data)
Open file descriptors
Signals
Current working directory
User and grouping IDs

Advantages of threads

There are several benefits in using threads. Threads are more efficient. The operating organisation does not need to create a new memory map for a new thread (as it does for a process). It also does not need to allocate new structures to keep runway of the land of open files and increment reference counts on open up file descriptors.

Threading also makes certain types of programming easy. While it'due south true that there's a potential for bugs because memory is shared amongst threads, shared memory makes it piffling to share information among threads. The same global and static variables can be read and written amidst all threads in a process.

A multithreaded application tin scale in functioning equally the number of processors or cores increases in a system. With a single-threaded process, the operating system can do aught to make let the process take reward of multiple processors. With a multithreaded application, the scheduler can schedule different threads to run in parallel on different cores or processors.

Thread programming patterns

There are several common means that threads are used in software:

Single job thread: This use of threading creates a thread for a specific chore that needs to be performed, ordinarily asynchronously from the main period of the plan. When the role is complete, the thread exits.
Worker threads: In this model, a process may have a number of distinct tasks that could be performed concurrently with each other. A thread is created for each one of these work items. Each of these threads and then picks of tasks from a queue for that specific work item. For example, in a word processing program, you may take a separate thread that is responsible for processing the user's input and other commands while another thread is responsible for generating the on-screen layout of the formatted page.
Thread pools: Hither, the process creates a number of threads upon commencement-up. All of these threads and then catch work items off the aforementioned work queue. Of course, protections need to be put in place that ii threads don't grab the same item for processing. This pattern is unremarkably found in multithreaded network services, where each incoming network request (say, for a web folio on a web server) volition be candy by a separate thread.

How the operating system manages threads

The operating organization saved information nearly each process in a procedure control block (PCB). These are organized in a procedure tabular array or list. Thread-specific data is stored in a data construction called a thread control cake (TCB). Since a process can have one or more threads (information technology has to have at to the lowest degree one; otherwise there's nothing to run!), each PCB will point to a list of TCBs.

Scheduling

A traditional, not-multithreaded operating organisation scheduled processes. A thread-enlightened operating system schedules threads, not processes. In the instance where a process has just one thread, in that location is no difference between the two. A scheduler should be aware of whether threads vest to the aforementioned process or non. Switching between threads of different processes entails a full context switch. Because threads that belong to unlike processes access different memory address spaces, the operating organisation has to affluent cache memory (or ensure that the hardware supports process tags) and flush the virtual memory TLB (the translation lookaside buffer, which is a cache of frequently-used retentiveness translations), unless the TLB likewise supports procedure tags. Information technology as well has to supercede the page table arrow in the retentiveness management unit to switch address spaces. The stardom betwixt scheduling threads from the same or a unlike procedure is also important for hyperthreaded processors, which support running multiple threads at the same fourth dimension but require that those threads share the same address space.

Kernel-level versus user-level threads

What we discussed thus far assumed that the operating organization is aware of the concept of threads and offers users system calls to create and manage threads. This form of thread back up is known equally kernel-level threads. The operating system has the ability to create multiple threads per process and the scheduler can coordinate when and how they run. Organisation calls are provided to command the creation, deletion, and synchronization of threads.

Threads can as well exist implemented strictly within a process, with the kernel treading the process as having a unmarried execution context (the archetype procedure: a single instruction arrow, saved registers, and stack). These threads are known as user-level threads. Users typically link their program with a threading library that offers functions to create, schedule, synchronize, and destroy threads.

To implement user-level threads, a threading library is responsible for treatment the saving and switching of the execution context from one thread to another. This means that it has to allocate a region of memory within the process that will serve every bit a stack for each thread. It also has to save and bandy registers and the instruction arrow as the library switches execution from one thread to another. The most primitive implementation of this is to take each thread periodically phone call the threading library to yield its use of the processor to some other thread — the illustration to a program getting context switched but when it requests to do so. A meliorate approach is to take the threading library ask the operating system for a timer-based interrupt (for example, see the setitimer system call). When the process gets the interrupt (via the indicate mechanism), the function in the threading library that registered for the signal is called and handles the saving of the current registers, stack pointer, and stack and restoring those items from the saved context of another thread.

One thing to spotter out for with user-level threads is the employ of organization calls. If any thread makes a system call that causes the process to block (recall, the operating system is unaware of the multiple threads), then every thread in the process is effectively blocked. We can avoid this if the operating system offers us non-blocking versions of system calls that tend to block for data. The threading library tin simulate blocking organization calls past using not-blocking versions and put the thread in a waiting queue until the system call'due south data is gear up. For instance, most POSIX (Linux, Unix, Bone X, *BSD) systems have a O_NONBLOCK option for the open organization call that causes a open and read to return immediately with an EAGAIN error code if no data is gear up. Also, the fcntl system phone call tin fix the O_ASYNC pick on a file that will crusade the process to receive a SIGIO signal when data is set for a file. The threading library can catch this signal and "wake up" the thread that was waiting for that specific information. Note that with user-level threads, the threading library will have to implement its own thread scheduler since the non-thread-aware operating system scheduler only schedules at the process granularity.

Why carp with user-level threads?

There are several obstacles with user-level threads. One big ane is that if ane thread executes a system call that causes the operating organisation to block so the entire process (all threads) is blocked. As we saw to a higher place, this could be overcome if the operating system gives us options to have not-blocking versions of system calls. A more pregnant obstacle is that the operating system schedules the process as a single-threaded entity and therefore cannot take advantage of multiple processors or hyperthreaded architectures.

At that place are several reasons, however, why user-level threads tin can exist preferable to kernel-level threads. All thread manipulation and thread switching is washed within the procedure so there is no need to switch to the operating organisation. That makes user-level threading lighter weight than kernel-level threads. Because the threading library must have its own thread scheduler, this can be optimized to the specific scheduling needs of the application. Threads don't have to rely on a full general-purpose scheduler of an operating system. Moreover, each multithreaded process may utilise its own scheduler that is optimized for its own needs. Finally, threading libraries can exist ported to multiple operating systems, allowing programmers to write more portable lawmaking since at that place volition be less dependence on the arrangement calls of a particular operating arrangement.

Combining user and kernel-level threads

If an operating system offers kernel-level thread support, that does not mean that you lot cannot use a user-level thread library. In fact, information technology's even possible to have a program utilise both user-level and kernel-level threads. An example of why this might be desirable is to have the thread library create several kernel threads to ensure that the operating organization can take advantage of hyperthreading or multiprocessing while using more efficient user-level threads when a very large number of threads is needed. Several user level threads tin can be run over a unmarried kernel-level thread. In general, the post-obit threading options be on most systems:

one:one: purely kernel threads, where one user thread always corresponds to a kernel thread.
Northward:one: only kernel threads, where Northward user-level threads are created on height of a single kernel thread. This is done in cases where the operating arrangement does not support multithreading or where you admittedly exercise non desire to use the kernel's multithreading capabilities.
North:M: This is known as hybrid threading and maps Due north user-level threads are mapped onto 1000 kernel-level threads.

Example: POSIX threads

1 popular threads programming package is POSIX Threads, divers equally POSIX.1c, Threads extensions (also IEEE Std 1003.1c–1995). POSIX is a family of IEEE standards that defines programming interfaces, commands, and related components for UNIX-derived operating systems. Systems such equally Apple's Mac OS X, Dominicus's (Oracle's) Solaris, and a dozen or so other systems are fully POSIX compliant and organisation such every bit about Linux distributions, OpenBSD, FreeBSD, and NetBSD are mostly compliant.

POSIX Threads defines an API (awarding programming interface) for managing threads. This interface is implemented as a native kernel threads interface on Solaris, Mac Os X, NetBSD, FreeBSD, and many other POSIX-compliant systems. Linux also supports a native POSIX thread library as of the 2.half-dozen kernel (as of December 2003). On Microsoft Windows systems, is available as an API library on peak of Win32 threads.

Nosotros volition not dive into a description of the POSIX threads API. There are many good references for that. Instead, nosotros will simply embrace a few of the very basic interfaces.

Create a thread

A new thread is created via:

          pthread_t t; pthread_create(&t, Nada, func, arg)

This call creates a new thread, t, and starts that thread executing function func(arg).

Exit a thread

A thread can get out past calling pthread_exit or just by returning from the first function that was invoked when it was created via pthread_create.

Join ii threads

Joining threads is coordinating to the wait system phone call that was used to permit the parent to observe the decease of a kid procedure.

          void *ret_val; pthread_join(t, &ret_val);

The thread that calls this function will wait (block) for thread t to stop. An important differentiator from the wait system phone call that was used for processes is that with threads there is no parent-child relationship. Any one thread may bring together (expect on) any other thread.

Stepping on each other

Because threads within a process share the same retention map and hence share all global information (static variables, global variables, and memory that is dynamically-allocated via malloc or new), mutual exclusion is a disquisitional part of application design. Mutual exclusion gives the states the assurance that we can create regions in which only one thread may execute at a fourth dimension. These regions are chosen disquisitional sections. Mutual exclusion controls allow a thread to grab a lock for a specific critical department (region of lawmaking) and exist sure that no other thread volition be able to take hold of that lock. Whatever other thread that tries to do and so volition go to sleep until the lock is released.

The pthread interface provides a elementary locking and unlocking mechanism to allow programs to handle mutual exclusion. An instance of grabbing and so releasing a critical section is:

          pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;     ... pthread_mutex_lock(&g); /* modify shared data */ pthread_mutex_unlock(&k);

References

Posix Threads Programming, Blaise Barney, Lawrence Livermore National Laboratory.
POSIX threads explained, part 1, Gentoo Linux Documentation, (follow links for Part two and Part three)
POSIX, Wikipedia article
Intel Hyper-Threading Technology: Your Questions Answered, Intel, May 2009.

This is an updated version of the original document, which was written on September 21, 2010.