C + + common face Test (eight) __c++

thread Pool

The thread pool is typically appropriate for the following scenarios:
(1) The Processing task is frequent and the task processing time is short in the unit time
(2) The requirement of real-time is higher. If you are creating a thread after you accept the task, you may not be able to meet the real-time requirements, so you must use the thread pool for pre-creation.
(3) must frequently face the high abrupt event , like the Web server, if has the football broadcast, then the server will have the huge impact. If you take the traditional approach at this point, you must constantly generate a large number of threads, destroy the thread. This can be avoided by adopting a dynamic thread pool at this time. High Concurrency Scenario

asynchronous I/O:
Multithreading, thread pooling
maintain a lot of long connections, and the switch is very frequent, the most efficient model is non-blocking, asynchronous IO model. and don't use Select/poll, these two APIs have the time complexity of O (N). in Linux with Epoll,bsd with Kqueue,windows IOCP, or with libevent encapsulated unified interface (for different platform libevent implementation with each platform-specific API), The API-specific time complexity for these platforms is O (1). In non-blocking, however, programming under the asynchronous I/O model is very painful. Because I/O operations are no longer blocked, message parsing needs to be guarded and the state of each link must be managed personally. And in order to fully utilize the CPU, you should also combine the thread pool to avoid processing business logic in polling threads.
https://www.zhihu.com/question/21516827
Epoll Technology with multithreading technology development
thread scheduling is a system resource overhead ... Theoretically, if there is no I/O wait and so the CPU idle things, the number of threads is best equal to the number of CPU core. The number of threads is best equal to the number of CPU cores ...

How the server is typically designed and developed. Distributed, decentralized, stateless, consistent hashing as few threads as possible to share conflicts as little as possible the number of threads in a lock-free job as much as possible to the CPU core as much as possible without waiting for the time slice of the thread logic as much as possible, avoid unnecessary encapsulation and forwarding engineering is not academic, OOP to the simple and easy to use high-performance good maintenance to make a pass ~ ~.

Epoll:edge Trigger, OneShot ... do not use epoll_wait () threads for too long to deal with epoll_wait () things. If you can use atomic, do not use mutexes(this is c++11) how to profoundly understand reactor and proactor. co-process

http://cnodejs.org/topic/58ddd7a303d476b42d34c911 Select, poll and Epoll