Thread pool and job queue architecture?

I have an epoll to receive incoming events and place them in a job queue.

When an event is placed on the job queue, a conditional pthread signal is sent to wake up worker threads.

However, I ran into a problem where all worker threads are busy and jobs are being kept in the queue. This is a serious problem because if Jobs are stacked and a new event does not arrive after a while, jobs in the queue will not be transferred to worker threads.

Once a thread is available, I want them to be able to automatically execute jobs from the job queue (if possible).

Is there anyway to do it? All I can think of is adding a Queue Observer and sending a conditional signal at intervals.

Also, I know that STL Queue is not thread safe. Does this mean that I have to block Mutex every time I access the STL Queue? Will this slow down my workflow?

Any suggestion to resolve this issue would be great.


source to share

2 answers

The classic way of counting / signaling jobs in a producer-consumer queue is to use a semaphore. The producer signals this after clicking on the job, and the consumer waits for it before pushing it out. To protect the queue from multiple access, you need a mutex around push / pop.



Take a look at a thread pool worker thread in .NET. Yes, you have to lock the global mutex, for this purpose I wrote a double-lock deque , so front / back operations can be done in parallel. I also have a lock-free deque , but the overhead is too high for client applications.



All Articles