Is Register Values Share Amoung Thrreads

Threads

Multiple flows of execution inside a procedure

February 5, 2014

Introduction

When we looked at the concept of the process, nosotros considered the stardom between a program and procedure. A process was a program 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 instruction pointer (program counter).

If we take a closer expect at the process, nosotros can pause it into ii components:

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

The second item is crucial for the execution flow of the program. The instruction pointer keeps rail of which instructions to execute side by side, and those instructions affect the registers. Subroutine telephone call/render instructions as well instructions that push or pop registers on the stack on entry to or exit from a part phone call adjust the contents of the stack and the stack pointer. This stream of instructions is the procedure' thread of execution.

A traditional process has ane thread of execution. The operating arrangement keeps track of the retentiveness map, saved registers, and stack pointer in the process control block and the operating system'southward scheduler is responsible for making sure that the procedure gets to run every once in a while.

Multithreading

Memory map with two threads — Retentivity map with ii threads

A process may be multithreaded, where the aforementioned program contains multiple concurrent threads of execution. An operating organisation that supports multithreading has a scheduler that is responsible for preempting and scheduling all threads of all processes.

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

An operating system had to keep rails of processes, and stored its per-process data in a data structure called a procedure control block (PCB). A multithread-enlightened operating arrangement also needs to keep track of threads. The items that the operating system must store that are unique to each thread are:

Thread ID
Saved registers, stack pointer, teaching pointer
Stack (local variables, temporary variables, return addresses)
Point mask
Priority (scheduling information)

The items that are shared amongst threads within a procedure are:

Text segment (instructions)
Data segment (static and global data)
BSS segment (uninitialized information)
Open up file descriptors
Signals
Current working directory
User and group IDs

Advantages of threads

There are several benefits in using threads. Threads are more efficient. The operating system does not need to create a new memory map for a new thread (as it does for a process). Information technology also does non need to classify new structures to keep track of the country of open up files and increase reference counts on open file descriptors.

Threading as well makes certain types of programming easy. While it'south true that there's a potential for bugs considering memory is shared among threads, shared memory makes it piffling to share data among threads. The aforementioned global and static variables can be read and written among all threads in a process.

A multithreaded application can calibration in performance as the number of processors or cores increases in a organisation. With a unmarried-threaded process, the operating system tin do zippo to make permit the process accept reward of multiple processors. With a multithreaded application, the scheduler can schedule unlike threads to run in parallel on unlike 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 task that needs to be performed, unremarkably asynchronously from the primary period of the plan. When the function is complete, the thread exits.
Worker threads: In this model, a procedure may have a number of distinct tasks that could exist performed concurrently with each other. A thread is created for each i of these work items. Each of these threads then picks of tasks from a queue for that specific piece of work item. For example, in a word processing program, you may have 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 folio.
Thread pools: Here, the process creates a number of threads upon outset-up. All of these threads so grab work items off the aforementioned piece of work queue. Of class, protections need to exist put in place that 2 threads don't grab the same detail for processing. This pattern is commonly institute in multithreaded network services, where each incoming network request (say, for a spider web folio on a spider web server) will be processed by a separate thread.

How the operating system manages threads

The operating system saved information about each process in a process control block (PCB). These are organized in a process table or list. Thread-specific information is stored in a data structure called a thread control block (TCB). Since a process tin have i or more threads (it has to have at least i; otherwise there's zippo to run!), each PCB will point to a list of TCBs.

Scheduling

A traditional, non-multithreaded operating system scheduled processes. A thread-aware operating system schedules threads, not processes. In the case where a procedure has just 1 thread, there is no divergence between the two. A scheduler should exist aware of whether threads belong to the same process or not. Switching between threads of different processes entails a total context switch. Considering threads that belong to different processes access different memory address spaces, the operating system has to flush enshroud memory (or ensure that the hardware supports procedure tags) and affluent the virtual memory TLB (the translation lookaside buffer, which is a enshroud of oft-used retentiveness translations), unless the TLB also supports procedure tags. It also has to replace the page tabular array arrow in the memory management unit to switch accost spaces. The distinction between scheduling threads from the aforementioned or a different procedure is as well important for hyperthreaded processors, which support running multiple threads at the same fourth dimension just require that those threads share the same address space.

Kernel-level versus user-level threads

What we discussed thus far assumed that the operating organisation is enlightened of the concept of threads and offers users system calls to create and manage threads. This course of thread support is known as 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. Organization calls are provided to control the cosmos, deletion, and synchronization of threads.

Threads tin also be implemented strictly within a process, with the kernel treading the process as having a unmarried execution context (the classic procedure: a unmarried instruction pointer, saved registers, and stack). These threads are known as user-level threads. Users typically link their plan 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 handling the saving and switching of the execution context from one thread to another. This means that it has to allocate a region of retentiveness within the procedure that volition serve as a stack for each thread. It besides has to save and swap registers and the education pointer every bit the library switches execution from one thread to another. The most primitive implementation of this is to accept each thread periodically call the threading library to yield its utilize of the processor to another thread — the analogy to a program getting context switched just when it requests to do so. A amend approach is to have the threading library ask the operating system for a timer-based interrupt (for instance, run across the setitimer system call). When the process gets the interrupt (via the signal mechanism), the office 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 some other thread.

One thing to watch out for with user-level threads is the use of arrangement calls. If any thread makes a arrangement call that causes the procedure to block (recall, the operating organization is unaware of the multiple threads), then every thread in the process is effectively blocked. Nosotros can avert this if the operating system offers us non-blocking versions of system calls that tend to block for information. The threading library tin simulate blocking system calls by using not-blocking versions and put the thread in a waiting queue until the organisation call's data is ready. For instance, most POSIX (Linux, Unix, Os Ten, *BSD) systems have a O_NONBLOCK selection for the open organisation call that causes a open up and read to return immediately with an EAGAIN fault lawmaking if no data is fix. Besides, the fcntl system call tin set the O_ASYNC option on a file that will cause the process to receive a SIGIO bespeak when information is ready for a file. The threading library tin catch this signal and "wake upwards" the thread that was waiting for that specific data. Notation that with user-level threads, the threading library volition have to implement its ain thread scheduler since the not-thread-aware operating system scheduler merely schedules at the process granularity.

Why bother with user-level threads?

At that place are several obstacles with user-level threads. One big ane is that if 1 thread executes a organization call that causes the operating system to block then the entire process (all threads) is blocked. As we saw above, this could be overcome if the operating organization gives united states options to have not-blocking versions of arrangement calls. A more than 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.

There are several reasons, however, why user-level threads can be preferable to kernel-level threads. All thread manipulation and thread switching is done within the procedure then at that place is no need to switch to the operating organization. That makes user-level threading lighter weight than kernel-level threads. Considering the threading library must take its ain thread scheduler, this can exist 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 procedure may employ its own scheduler that is optimized for its own needs. Finally, threading libraries tin exist ported to multiple operating systems, allowing programmers to write more than portable code since there will be less dependence on the organisation calls of a item operating organisation.

Combining user and kernel-level threads

If an operating system offers kernel-level thread back up, that does non hateful that you cannot use a user-level thread library. In fact, it'due south even possible to have a program use both user-level and kernel-level threads. An case of why this might exist desirable is to have the thread library create several kernel threads to ensure that the operating system can take reward of hyperthreading or multiprocessing while using more efficient user-level threads when a very big number of threads is needed. Several user level threads can be run over a unmarried kernel-level thread. In general, the following threading options exist on most systems:

one:1: purely kernel threads, where one user thread always corresponds to a kernel thread.
N:1: only kernel threads, where N user-level threads are created on peak of a unmarried kernel thread. This is done in cases where the operating organisation does non support multithreading or where yous absolutely do not want to use the kernel'south multithreading capabilities.
N:M: This is known as hybrid threading and maps N user-level threads are mapped onto Thou kernel-level threads.

Case: POSIX threads

One popular threads programming packet is POSIX Threads, defined as POSIX.1c, Threads extensions (besides 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 as Apple's Mac OS X, Lord's day'south (Oracle's) Solaris, and a dozen or so other systems are fully POSIX compliant and organisation such every bit almost Linux distributions, OpenBSD, FreeBSD, and NetBSD are more often than not compliant.

POSIX Threads defines an API (application programming interface) for managing threads. This interface is implemented as a native kernel threads interface on Solaris, Mac Bone X, NetBSD, FreeBSD, and many other POSIX-compliant systems. Linux besides supports a native POSIX thread library as of the two.6 kernel (as of December 2003). On Microsoft Windows systems, is available as an API library on top of Win32 threads.

Nosotros will non dive into a description of the POSIX threads API. In that location are many practiced references for that. Instead, we will just cover a few of the very bones interfaces.

Create a thread

A new thread is created via:

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

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

Go out a thread

A thread can leave by calling pthread_exit or just by returning from the beginning function that was invoked when it was created via pthread_create.

Join 2 threads

Joining threads is coordinating to the wait system telephone call that was used to let the parent to detect the death of a child process.

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

The thread that calls this function will wait (block) for thread t to terminate. An important differentiator from the look arrangement call that was used for processes is that with threads in that location is no parent-kid human relationship. Any ane thread may join (look on) any other thread.

Stepping on each other

Considering threads within a process share the same memory 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 critical part of awarding design. Mutual exclusion gives us the balls that we can create regions in which only one thread may execute at a time. These regions are chosen critical sections. Common exclusion controls allow a thread to grab a lock for a specific critical section (region of code) and be sure that no other thread will be able to grab that lock. Any other thread that tries to do and so will get to sleep until the lock is released.

The pthread interface provides a simple locking and unlocking mechanism to allow programs to handle mutual exclusion. An example of grabbing and then releasing a disquisitional section is:

          pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;     ... pthread_mutex_lock(&m); /* modify shared information */ pthread_mutex_unlock(&m);

References

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

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