The architecture of multi-threaded program and single process programs

Both multithreaded and single-process programs are used in network services. multithreaded programs are primarily used to process some requests synchronously, in order to process more requests at the same time. Generally take the thread pool policy, a main thread to allocate the request.

(i) Common process models:

(1) Multithreaded model

This mode secures the number of threads, and the throughput is close to the number of throughput * threads per thread. Not scalability, scalability is not strong, under high load capacity has a great limit. For synchronous data access applications with little load, it is quite extensive.

(2) Multithreading model two

This model is a thread that is responsible for dispatching tasks to different threads, usually maintaining a thread pool, the number of threads in the pool can be scaled, and determined by the scheduling thread. The payoff is also handled by scheduling threads, which can communicate between threads and threads through shared memory to obtain other means. However, the maximum number of threads is also limited.

(1) Single process model

This model uses a fully asynchronous Pattern processing request, the process maintains a global queue for each request, the work process and the network process is independent, the use of shared memory mode for communication, in the case of full asynchronous, can also achieve high concurrency, and high throughput. This model is easy to control and requires protection against overloads.

(ii) Comparison of several common models

(1) Complexity of program

The most complex is the use of a scheduling function of the thread pool, this model requires a scheduling thread, the task of scheduling threads to do include assigning worker threads, overload protection, communication with multiple threads, synchronization. Shared resources between threads are locked, and threads can eliminate shared resources and improve processing power. It can be accessed in a synchronous mode of processing, but with greater risk.

The single-process model is relatively simple, and a process is going to complete all the functions, including packet handling, logic processing, and overload protection.

(2) Performance

Generally speaking, the front-end receives the request, has the multi-client, the multi-version, the multi-protocol is suitable to adopt the multithreading pattern, if has the unified protocol format, then should adopt the thread pool which has the dispatch threads to complete. If the protocol is different, you need to use different threads to listen for different ports to resolve.

Background services are generally suitable for single-process use. Background threads require high concurrency and high throughput. The single-process model eliminates locks and avoids many complex problems with multithreading. Multithreading in the development process there is a big drawback is not conducive to debugging. The developer's tuning skills are highly demanding.

Backstage also have the use of multi-threaded, backstage background generally use single process.

(3) Competition

Multi-threaded There is a competition problem, multithreading will encounter many program traps, global data, queues, maps and other data structures need to be locked

Single-threaded programs obviously do not have a competitive problem, and single-threaded programming in the program is relatively straightforward. Many timing and competitive issues do not exist.

(4) Robustness of service

In multiple threads, any thread that has a problem can cause the entire process to hang up, which is no different from a single process. One of the benefits of multithreading is the ability to invoke synchronous APIs, whereas single-process network services generally allow only asynchronous APIs to be called.

Original link: http://blog.csdn.net/kingsleer/article/details/7661007