Go: Processes and Threads

Linux process and threading principles (i) 2010-05-27 11:43:52

Category: Linux

In the 11th chapter, we see how processes are handled in Linux. These multi-process features have long been the property of Unix-like operating systems. Sometimes the cost of creating a new process with fork is too great. In this case, it is useful to make a program do two things at the same time, or at least appear to be so. Correspondingly, we may wish to have two or more things happen in the same way. This is where the thread begins.

In this chapter, we will understand:

Create a thread within a process
Synchronizing data between multiple threads in a process
Modify the properties of a thread
One thread controls another in the same process

what is a thread

Multiple lines of execution within a program are called threads. A more precise definition is that a thread is an in-process control queue. All the programs we've seen so far have been executed as a single process, and Linux has the ability to run multiple processes concurrently, although similar to many other operating systems. Indeed, all processes have at least one thread of execution. All the processes we have seen so far in this book have only one thread of execution.

It is important to distinguish between the fork system calls and the creation of new threads. When a process executes a fork system call, it creates a copy of the process with its own variable and PID. This new process is scheduled separately, and (usually) its execution is independent of the process that created him. When we create a new thread within the process, the execution of the new thread has its own stack (and thus the local variable), but the shared global variable, the file descriptor, the signal processor, and its current directory are the same as the process that created him.

The concept of threads has been around for some time, but until the IEEE POSIX commission publishes some standards, they are not widely available in Unix-like operating systems, and their implementations do change between different providers. With the POSIX 1003.1c specification, everything changed; threads are not only standardized, they are available in most Linux distributions.

Linux first uses a library that is usually "linuxthreads" to support threads around 1996. This is very close to the POSIX standard (indeed, many differences are not obvious for a variety of reasons), and he is an important step in making Linux programs use threads for the first time. However, there are some small differences between the Linux implementation and the POSIX standard, most of which are related to signal processing. These restrictions do not manifest in the implementation of the library, and more restrictions are due to the Linux kernel's underlying support.

Many projects focus on how threading support on Linux can be improved, not just the difference between the Linux implementation and the POSIX standard. Many jobs will center on how the user layer thread should map to the kernel layer thread. The two main items are the new Generation POSIX thread (NGPT) and the native POSIX thread Library (NPTL). Two projects have made modifications to the Linux kernel to support new libraries, and have provided significant performance improvements on older Linux threads.

In 2002, the NGPT team declared that they did not want to split the community, and stopped adding new features to NGPT, but continued to work on Linux threading support, with their important contribution behind the NPTL effort. So, it's clear that NPTL will become the new threading standard on Linux, and the first NPTL mainline version appears in red Hat Linux 9. Some interesting background information about NPTL can be found in an article called "The Native POSIX Thread Library for Linux".

Most of the code in this chapter will use this line libraries because he is based on the POSIX standard. However, if we have not used NPTL, we will find it strange, especially when they run when we use PS to view it. Using the old Linux line libraries, we usually see multiple processes, usually more than the ones we execute, and with NPTL, we see only one program, although there are multiple threads inside it.

Advantages and disadvantages of threading

Under certain conditions, creating a thread has some special advantages over the creation of a new process. Creating a new thread is much less expensive than creating a new one (although Linux is particularly efficient in creating processes compared to other operating systems).

Here are some examples of using threads:

Sometimes it is useful to make a program seem to do two things at the same time. A classic example is the real-time word count on a document while editing text. A thread can manage the user's input and perform edits. Another thread that can see the contents of the document can continuously update the word count variable. The previous thread (or a third thread) can use this shared variable to alert the user. Another example is a multithreaded data server, which uses threads to improve load data by serving multiple requests when a process serves multiple customers. For a data server, transparent multitasking can be difficult to accomplish effectively in different processes because it requires locks, and data consistency causes different processes to be difficult to synchronize. It is much easier to use multithreading than to use multiple processes to solve this situation.

Mixed-use input, calculation and output of the program by using it as three separate threads to run, the program's performance will be greatly improved. When the input or output thread waits for a connection, the other can continue to run. So, when the program can only do one thing at a time, the thread can make a program do something useful while waiting for the connection. Handling multiple network connection server programs is an example of a multi-threaded application.

In general, switching between threads is much smaller for the operating system than switching between processes. Therefore, multithreading is less dependent on system resources than multiple processes, which is more practical for programs that logically require multiple threads of execution on a single processor system. In other words, the difficulty of writing a multithreaded program is large and should not be underestimated.

Disadvantages of threading:

Programming a multithreaded program requires careful design. The introduction of potential time errors, or problems caused by unexpected shared variables in a multithreaded program, need to be taken into account. Alan Cox has evaluated that threads are called "How to shoot both feet at the same time".

Debugging multithreaded programs is much more difficult than debugging a single-threaded program because the interaction between threads is very difficult to control.

Dividing a large calculation into two parts and running the two parts as different threads on a single processor machine does not necessarily run fast, because there are only so many CPU cycles, and although no other programs are trying to run, and we only have multi-processor or hyper-threading CPU, the multithreading approach gains benefits.

Go: Processes and Threads