Common programming models for multithreaded servers

This article is mainly about my personal experience in multithreading development. This paper summarizes one or two kinds of common threading models, sums up the best practice of interprocess communication and thread synchronization, in order to develop multithreaded programs in a simple and normative way.

The "Multithreaded server" in this article refers to an exclusive network application running on a Linux operating system. Hardware platform for the Intel x64 series of multi-core CPUs, single or dual SMP server (each machine has four cores or eight cores, more than 10 GB of memory), between the machine with a hundred gigabit or Gigabit Ethernet connection. This is probably the current civilian PC server mainstream configuration.

This article does not cover Windows systems, does not involve a human-computer interface (regardless of the command line or graphics), does not take into account the file read/write (except to disk writes log), does not consider the database operation, does not consider the WEB application; Do not consider high-end >=32 nuclear Unix mainframe, only TCP, no UDP, and no other than the local network in addition to other data transceiver methods (such as serial port, USB port, data acquisition board, real-time control, etc.).

With all the above restrictions, the basic functions of the "Web application" that I'm going to talk about can be summed up as "receive data, count it, send it again". In this simplified model, it seems that there is no need to use multithreading, a single thread should also be able to do very well. "Why do I need to write multithreaded?" This issue is easy to provoke a war of words, I put into another blog to discuss. Let me first assume the context of multithreaded programming.

The word "server" sometimes refers to a program, sometimes to a process, sometimes to hardware (whether virtual or real), and note the distinction by context. In addition, this article does not consider virtualization scenarios, when I say "two processes are not on the same machine," refers to the logic does not run in the same operating system, although physically may be in the same machine virtual two "virtual machine" on.

This article assumes that the reader already has knowledge and experience in multithreaded programming, which is not an introductory tutorial.

This article is thanks to Mr. Milo Yip for his perusal. Of course, I am responsible for any mistakes in this article.

1 Processes and Threads

"Process/process" is one of the two most important concepts in the operation (the other is a file), roughly speaking, a process is "running in memory". The process in this article refers to the thing that the Linux operating system generates through the fork () system call, or the product of Windows CreateProcess (), not the lightweight process in Erlang.

Each process has its own separate address spaces, "in the same process" or "not in the same process" is an important decision point for system function partitioning. Erlang's "process" metaphor for "people", I feel very precise, provides us with a framework for thinking.

Each person has his or her own memory (memory), people communicate through conversation (messaging), conversations can be either interviews (the same server) or on the phone (different servers, network communications). The difference between interviewing and talking on the phone is that the interview can immediately know if the other person died (crash, SIGCHLD), and the phone talk can only be judged by the periodic heartbeat to see if the other person is still alive.

With these metaphors, the design of distributed systems can take "role playing", and several people in the team play a process in which the role of the person is determined by the process's code (the login, the distribution of messages, the management of the sale, etc.). Everyone has their own memories, but do not know other people's memories, to know other people's views, only through conversation. (The IPC is not considered for shared memory.) Then you can think about fault tolerance (in case someone suddenly dies), capacity expansion (added in), load balance (to move A's work to B), retire (A to fix the bug, do not give him a new job, and so he finished the things on his hands to restart) and so on all kinds of scenes, very convenient.

The concept of "threading" has probably been in vogue since the 1993, only more than 10 years ago, a Unix operating system that had no more than 40 years of glorious history. The presence of threads has added chaos to Unix, and many C-Library functions (Strtok (), CTime ()) are not thread-safe and need to be redefined; signal semantics are also greatly complicated. As far as I know, the first (civilian) operating system that supports multithreaded programming is Solaris 2.2 and Windows NT 3.1, both of which were published in 1993. Subsequently in 1995, the POSIX threads standard was established.

Threads are characterized by sharing the address space so that data can be shared efficiently. Multiple processes on a single machine can efficiently share code snippets (the operating system can be mapped to the same physical memory), but cannot share data. If multiple processes share a large amount of memory, it is tantamount to writing a multiple process program as multithreading.

The value of multithreading, I think, is to better serve the performance of symmetric multipath processing (SMP). Multithreading does not have much value until it is SMP. Alan Cox said that a computer is a state machine. Threads are for people who can ' T program State machines. (The computer is a state machine.) Threads are intended for people who are unable to write a state machine program. If there is only one execution unit, one CPU, then indeed, as Alan Cox says, writing a program in a state machine is the most efficient, which is exactly the programming model shown in the next section.