3

I have an epoll to receive incoming events and put them into a Job Queue.

When the event is put into Job Queue, pthread conditional signal is sent to wake up the worker threads.

However I've met a problem where all worker threads are busy and Jobs keep stacks up on the queue. This is serious problem because if Jobs are stacked, and new event doesn't come in a while, Jobs in Queue won't be handed to Worker Threads.

As soon as Thread gets available, I wish they can take jobs from the Job Queue automatically (if Possible).

Is there anyway to do this? All I can think of is.. adding a Queue Observer and send a conditional Signal in intervals.

Also, I know that STL Queue is not thread-safe. Does that mean I have to Mutex Lock everytime when I get an access to STL Queue? WOn't this slow down my working process?

Any suggestion to solve this problem will be great.

Jae Park
  • 621
  • 4
  • 13
  • 27
  • Regarding the stl queue, you definitely need to manage access to the queue object with a lock if it is being accessed/modified from different threads. Whether the overhead is significant is determined by the amount of contention for the lock, which is related to the number of active threads and the time they spend processing each job. – JS. Mar 08 '12 at 01:03
  • First, don't worry too much about the performance, try to make it work should be your priority. It it doesn't work very fast, it won't be useful ;) Then, I'll guess you should already have a mutex to use with your cv that you can use to protect the queue. I really doubt you can do it without a mutex anyway. – J.N. Mar 08 '12 at 01:05
  • That said, there are some libraries that are already good at this, boost.threadpool for instance. Unless you have some very precise requirements, using a premade one is a better idea. Last, don't try to have tasks too small. If your jobs are really small, then you will lose time in the bookkeeping. If it happens regroup them in batches of 10 or 100 if possible. – J.N. Mar 08 '12 at 01:07
  • @J.N. u mean boost.thread_group right? – Jae Park Mar 08 '12 at 01:10
  • No, I meant boost.threadpool, it is not yet an official boost library. See this link http://threadpool.sourceforge.net/. – J.N. Mar 08 '12 at 01:11
  • I already posted this link http://stackoverflow.com/a/5538447/104774 as a comment to your previous question (http://stackoverflow.com/questions/9598034/what-happens-if-no-threads-are-waiting-and-condition-signal-was-sent) – stefaanv Mar 08 '12 at 08:22

2 Answers2

2

The classic way of counting/signaling jobs on a producer-consumer queue is to use a semaphore. The producer signals it after pushing on a job and the consumer waits on it before popping one off. You need a mutex around the push/pop as well to protect the queue from multiple access.

Martin James
  • 24,453
  • 3
  • 36
  • 60
0

Take a look at the work-stealing thread pool in .NET. Yes you'll have to mutex lock the global queue, to that end I've written a double-lock deque so operations on the front / back can be done in parallel. I also have a lock-free deque but the overhead is too high for client-side apps.

Qarterd
  • 280
  • 3
  • 5