Linux multithreaded Practice (1)--Threading theory

Threading Concepts

An execution path in a program is called a thread. A more accurate definition is that a thread is a "control sequence/sequence of instructions within a process ";

All processes have at least one thread of execution;

process VS. Threads

1. A process is the basic unit of Resource allocation (processes need to participate in the competition of resources), while threads are the smallest unit of processor scheduling (program execution);

2. Threads share process data, but also have their own part (very few O (∩_∩) o~) data, such as thread ID, program counter, a set of registers, stacks, errno (error code), signal status, priority, etc.;

3. Threads within a process can share resources such as code snippets, data segments, open files and signals, and so on.

Fork VS. Pthread_create

When a process executes a fork call, a new copy of the process is created, and the new process will have its own variable and its own PID. The running time of this new process is independent, and it is executed almost entirely independently of the process that created it (its parent process).

When a new thread is created in the process, the new execution thread will have its own stack (and hence its own local variable), but share the global variable , file descriptor with its creator , signal processor and current working directory status (for example: top three items Code,data,files is shared! ) );

Threading Benefits

Q The cost of creating a new thread is much smaller than creating a new process (so sometimes thread is called a lightweight process)

Q Switching between threads requires much less work done by the operating system than switching between processes (increased concurrency)

Q threads consume much less resources than processes

Q can take advantage of the number of concurrent processors

Q While waiting for slow I/O operations to end, the program can perform other computational tasks

Q Compute-intensive applications, in order to be able to run on multiprocessor systems, decompose computations into multiple threads to implement

Q I/O intensive applications, in order to improve performance, overlap I/O operations. Threads can wait for different I/O operations at the same time

Thread disadvantage

Q Performance Loss

A computationally-intensive thread that is rarely blocked by external events often cannot share the same processor with its threads . If the number of compute-intensive threads is more than the available processors, there may be a significant performance penalty, where the performance penalty is to increase the additional synchronization and scheduling overhead, while the available resources are the same.

Q Robustness Reduction

Writing multithreading requires a more comprehensive and in-depth consideration, and in a multithreaded program, there is a great chance that a small deviation in time allocation or a bad impact due to shared variables should not be shared, so if one thread crashes in one process it can cause other threads to crash! In other words There is a lack of protection between threads.

Q Lack of access control

A process is the basic granularity of access control, such as invoking some OS functions in one thread, affecting the entire process, such as changing the current working directory in one thread, and other threads changing as well.

Q Programming Difficulty improved

It is much more difficult to write and debug a multithreaded program than a single thread.

Thread Scheduling Competition Range

The operating system provides a variety of models for scheduling application-created threads. The main difference between these models is that when competing for system resources (especially CPU time), the Thread Scheduling competition range (thread-scheduling contention scope) is different:

1. Process contention scope: Each thread competes for "scheduled CPU time" in the same process (but does not compete directly with threads in other processes).

2. System contention scope: threads compete directly with other threads in system-wide.

more Threading Model

1. n:1[to map multiple user-level threads to a kernel-level thread, the thread implementation of an earlier OS]

Thread implementation is based on the process control mechanism and is managed by the Library of user space. The OS kernel does not know the thread information at all. These threads are called user-space threads.

These threads work in the " Process competition range ";

Advantage: In the N:1 threading model, the kernel does not interfere with any of the thread's life activities , nor does it interfere with thread environment switching in the same process. Thread management is a real user space, so the efficiency is high;

Disadvantages:

(1) Multiple threads in a process can only be dispatched to one CPU, which limits the amount of concurrent use available.

(2) If a thread performs a "blocking" operation (such as read), all threads in the process will block until the end of the operation. For this reason, some threads are implemented to provide wrappers for these blocking functions and replace those system calls with non-blocking versions to eliminate this limitation.

2.1:1[map Each user-level thread to a kernel-level thread]

In the 1:1 core threading model, every thread created by an application is managed directly by a core thread .

Each core thread is tuned to the system CPU by the OS kernel, so all threads work in the " System race range ".

Advantage: When one thread is blocked, allowing another thread to continue running increases concurrency, but the creation and scheduling of such threads is done by the kernel because the overhead of such threads is large ( but generally less than the process overhead)

3. n:m[maps N User-level threads to M kernel-level threads, requires n>=m, contemporary POSIX threads (that is, the threading model currently used by Linux)]

The N:M threading model provides level two control that maps a user thread to a system's scheduler to implement a parallel LWP, which is called a lightweight process (Lwp:lightweight), and the LWP is mapped to the core thread in one by one. [Thread---LWP---core thread (participating in scheduling)]

A lightweight process is a user thread supported by the kernel and an abstract object for kernel threads. Each thread has one or more lightweight threads, and each lightweight thread is bound to one kernel thread, respectively .

N:M threading Model overcomes the disadvantage of low concurrency of many-to-one model, and overcomes the disadvantage that one user thread of a single model takes up too many kernel-level threads and has too much overhead. also has many pairs one, the individual model's respective merit, could be described as set two the length of the family;

Thread Implementation Classification

(1) User-level threading

The user-level thread mainly solves the problem of context switching, and its scheduling algorithm and scheduling process are all determined by the user, and no specific kernel support is required at runtime. Here, the operating system tends to provide a user-space line libraries, which libraries provides the ability to create, dispatch, and revoke threads, while the kernel still manages only the processes. If a thread in a process calls a blocked system call function, the process includes all other threads in the process are also blocked at the same time. The main disadvantage of this user-level thread is the inability to perform multiprocessor benefits in the scheduling of multiple threads in a process.

(2) kernel-level threading

This thread allows threads in different processes to be dispatched according to the same relative priority scheduling method, so that the concurrency benefits of multiprocessor can be played.

Most systems now employ user-level threads that coexist with core-level threads . A user-level thread can correspond to one or several core-level threads, that is, a "one-to-many" or "multi-pair" model. This can meet the needs of multiprocessor system, but also minimize the scheduling overhead.

Summarize:

Using threading mechanisms greatly speeds up context switching and saves a lot of resources . However, because of the scheduling management in both the user and kernel states, the complexity of the implementation and the likelihood of priority rollover are increased. The synchronization design and debugging of a multi-thread program will also increase the difficulty of the implementation.

Linux multithreaded Practice (1)--Threading theory