Advantages and disadvantages of multi-process and multithreading

Transferred from: http://m.blog.chinaunix.net/uid-29131868-id-5155428.html

How the Linux kernel supports multiple processes and multithreading:

The threading mechanism supports concurrent programming techniques and can really guarantee parallel processing on multiprocessor. The Linux implementation thread is special, and Linux treats all the threads as a process implementation. Linux threads look like normal processes (only the process and other processes share resources, such as address space). These mechanisms differ greatly from Microsoft Windows or Sun Solaris implementations.

The thread implementation of Linux is done outside the core, and the kernel provides the interface Do_fork () that creates the process. The kernel provides two system calls, __clone () and fork (), and eventually calls the Do_fork () kernel API with different parameters. Do_fork () provides a number of parameters, including CLONE_VM (shared memory space), CLONE_FS (shared file system Information), Clone_files (Shared file descriptor table), Clone_sighand (shared signal handle tables), and Clone_ PID (Shared process ID, only valid for the core process, that is, process # No. 0). When a multi-process is generated using a fork system call, the kernel calls Do_fork () without using any shared properties, and the process has a separate running environment. When using Pthread_create () to create a thread, all of these properties are eventually set to call __clone (), and all of these parameters are passed to the Do_fork () in the kernel, thus creating a "process" that has a shared running environment, and only the stack is independent, by __clone ( Incoming

That is, under Linux , whether it is multithreaded programming or multi-process programming, the end is to use do_fork Implementation of multi-process programming, but the process is created with different parameters, resulting in a different shared environment. Linux threads exist in the kernel in the form of lightweight processes, with separate process table entries, and all creation, synchronization, and deletion operations are performed in the Pthread library. The Pthread library uses a management thread (__pthread_manager (), each process is independent and unique) to manage the creation and termination of threads, assigns thread IDs to threads, sends thread-related signals, and the primary thread Pthread_create ()) The caller passes the request information through the pipeline to the management thread.

Many friends say that the advantage of using multithreading is that resources take up less, which implies that the process consumes more resources than threads, right? But is it true that Linux processes are actually using a lot of resources? For the moment, if the process is more resource-intensive than the thread, Linux is actually doing quite a lot of savings in terms of how much the process consumes resources. Generating a multi-process is certainly a bit of memory to be produced to replicate the process table entry, which is a task_struct structure, but the structure itself is quite small. What other data segments, code snippets, and stack segments must be duplicated for a process? For multi-process, the code snippet is definitely not replicated, because the parent process and the code snippets for each child process are the same, data segments and stack segments? Not necessarily, because a technology widely used in Linux is called Copy-on-write, which is a write-time copy. What does copy-on-write mean? means resource savings, assuming that a variable x exists in the parent process, when the parent process creates a child process or multiple sub-processes, does this variable x replicate to the memory space of the child process? No, the child process and the parent process use a variable of the same memory space, but when the child process or parent process changes the value of the variable x, the variable is copied, causing the variable values in the parent-child process to be different. The parent-child process variables do not affect each other, and because the parent-child process address space is completely separated, the address of the variable can be exactly the same .

Linux's "Threads" and "processes" are actually at a scheduling level, sharing a process identifier space, which makes it impossible to implement the POSIX threading mechanism on Linux, so many Linux line libraries implementations can only implement most of the POSIX semantics and is as close to function as possible. The creation of the Linux process is very rapid. The kernel design and implementation book even points out that the speed of the Linux creation process is very good compared to other thread-optimized operating systems (Windows,solaris) that create threads, which means that the creation is fast. Because the asynchronous signal is distributed by the kernel as a process, and each thread of linuxthreads is a process for the kernel and does not implement a "thread group", some semantics do not conform to the POSIX standard, such as not implementing a signal to all threads in the process, as explained by the Readme. The thread synchronization in Linuxthreads is largely based on the signal, and the efficiency is always a problem through the synchronous mode of the complex signal processing mechanism of the kernel. Linuxthreads issues, especially compatibility issues, have severely hampered the use of multithreaded designs on Linux for cross-platform applications, such as Apache, so that threading applications on Linux have remained at a relatively low level. There are already many people in the Linux community who are working to improve threading performance, including both user-level line libraries and line libraries that are both core and user-level with improved. At present, there are two projects, one is the NPTL (Native POSIX Thread Library) led by Redhat Company, the other is IBM Investment development NGPT (Next Generation POSIX threading), Both are built around a fully compatible POSIX 1003.1c, while doing work within and out of the core to implement a multi-pair multithreaded model. Both of these models compensate for the shortcomings of linuxthreads, and are all reinvent new designs.

To sum up the conclusion is that in Linux Programming Multi-process programming with less multi-threaded programming.

IBM has a guy who did a test and found that Windows is a lot faster than Linux when switching threads. In and out of the fastest locks (windows2k's critical section and Linux Pthread_mutex), Windows is about five times times faster than Linux. Of course, this is not to say that Linux is not good, and after the actual programming, in general I think Linux is more suitable for high performance server, but in the specific area of multithreading, Linux is less than Windows. This should be justifiable, after all, the Unix family is from a multi-process, and windows from the beginning is multi-threaded.

If the Unix/linux environment, the use of multithreading is not necessary.

Multithreading is higher than multi-process performance? Mislead!

It should be said that multithreading is less expensive than multi-process, but less performance .

In the UNIX environment, there is no significant difference between multi-process scheduling overhead and multithreaded scheduling overhead, that is, UNIX process scheduling efficiency is very high. In terms of memory consumption, both the global data area, now memory is very cheap, server memory is a few g, is not a problem at all.

Multi-process is a three-dimensional traffic system, although the cost is high, uphill downhill more oil, but not traffic jams.

Multithreading is a plane traffic system, low cost, but too many traffic lights, old traffic jams.

We are now open sports cars, oil (main frequency) Some, not afraid of uphill downhill, afraid of traffic jams.

High-performance transactional server middleware, such as Tuxedo, is a multi-process proposition. The actual test shows that tuxedo performance and concurrency efficiency are very high. Tuxedo is Bell Labs, and Unix ancestry, should be the most profound understanding of UNIX, their views should have a great reference significance.

Advantages and disadvantages of multi-process and multithreading