One reason: Recently, due to work problems, a simple thread pool needs to be implemented to meet the following requirements,
- Scalable, that is, the thread can be added dynamically once the thread is found to be insufficient. (As for thread reduction, this may be difficult and will not be considered for the moment ).
- Timeout tasks are supported. For example, to submit a task, you can set the task to be executed after 5 seconds, and set the task to be executed once or every 5 seconds.
These two requirements are basically met. The following describes implementation issues. Ii. Windows platform 1 Windows platform implements a thread pool (do not use the completion port). My first thought was:
- Create 20 threads, for example, and all the 20 threads are waitforxxxobject in an event.
- This event is triggered when a task is added. In order to avoid group alarms (for example, when there is only one task, 20 threads are all up to grab the task, and 19 other threads are white. This causes a significant reduction in system efficiency .), When createevent is enabled, you can set it to ensure that only one waiting thread starts.
Problem:
- Which of the 20 threads should perform the timeout check? Although the wait function provides a timeout mechanism, it is impossible for these 20 functions to perform timeout detection?
- The solution is that you may need a separate thread to regularly check the task, add the expired task to the task queue header, and then trigger the event so that other threads can get the task smoothly.
- In another way, one of the 20 threads performs a timeout check and then executes the first task to expire. The problem is that if the task executed by this thread takes too long, other time-out tasks cannot be executed.
- It is better to use a separate thread for comprehensive consideration.
2. Use the complete port on Windows
- It is easy to use the finished port, and the number of threads in the thread pool will be twice the number of CPUs (this is the recommended value and should be the choice of most people ).
- When wait occurs, the kernel automatically schedules a thread for execution. In addition, successive tasks tend to be executed in the same thread. This reduces the thread switching time. Therefore, the surprise group effect is not guaranteed by the kernel.
- There is no better way to solve the timeout task check. You can only use the same method as above.
3. Linux platform 1 the basic idea of implementing a thread pool on Linux is the same as that on Windows. However, because the thread synchronization primitive (POSIX) provided by Linux is not as easy to use as windows, there are some special points to note:
- In Windows, the event is used for inter-thread notifications. in Linux, POSIX condition + mutex can also be used to perform the same operation, however, this method is rarely used in Linux, but pipe is widely used to create two FD instances. When thread 1 wants to wake up thread 2, it can write data to writefd, so that thread 2 can be blocked and returned in readfd. I didn't understand why pipe was used before, But I suddenly figured it out. Because the blocking method on Linux uses select, poll, and epoll, where FD is waited, the FD method can be used to call the method in a unified manner. (Due to the lack of waitformultiobject in POSIX, there is a series of implementation of wait/createevent in Linux on the Internet, which is difficult to download. Haha)
- However, there are now 20 threads, so it is impossible to create 20 pipelines? Even if there are 20 pipe, I have to write data to the writefd of the thread to which I want to wake up. This is obviously not a good solution. Only condition + mutex can be used. To avoid group alarms, you can only use signal instead of broadcast when operating cond.
- Timeout tasks can be processed in the same way as windows.
Four actual thread pool Designs
- For users, the thread pool processes tasks. Therefore, tasks should be added to the thread pool. The task has three priorities: High, Medium, and low. In addition, some tasks need to occupy threads all the time, so they also distinguish between persist and non-persist. At the design time, there are three Priority Queues: High, Medium, and low. When selecting a task, the thread pool first processes the task with a high priority and then the task with a low or medium priority.
- When the number of threads in the thread pool is smaller than the number of tasks, the thread pool should automatically add threads in the pool. This is automatic scaling. When a thread in the thread pool detects that it has not been working for a long time and the number of threads in the pool exceeds the maximum value, the thread should exit automatically. In this way, we can achieve a better automatic reduction. In this case, each thread needs a timeout check to see if it is unnecessary.
- For fixed/time-out tasks, a job with a high priority of persist must be added to the thread pool. This job comes with a scheduled task queue. To add a scheduled task is to add members to the queue. Then wake up the thread. This thread selects a task from it and submits it to the thread pool. (In fact, our solution on Windows)
