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
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.
source to share
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.
source to share