[Openmcl-devel] thread pool question

[Erik Pearson]

So you guys are suggesting a system of a controlling thread and  
multiple worker threads, each with their own "job" queue? If so, what  
do you see as the advantage of this over a single queue?

a. job queue per worker thread

A new job (i.e. function to be run) is allocated via a sever thread  
or at least some sort of server api to the worker thread which has  
the least number of jobs queued, or to the first thread with 0 jobs.  
This would entail polling worker thread queues (at least a variable)  
for the current size, and a lock and a semaphore per worker thread.

b. single thread queue

The job is pushed onto a single queue (while locking), and a single  
semaphore is incremented. Each worker waits on this semaphore, and  
will try to obtain the next job in the queue when it wakes up,  
obtaining a lock created in the server thread. There doesn't seem to  
be any need for a master thread, other than the main thread in which  
the application is running, since the work of adding a new job to the  
queue is trivial (er, unless there ends up being a long queue of  
locks waiting on the job queue...)

It seems like the worker thread with queues design is a bit more  
resource intensive (more locks and more semaphores) and involves more  
work when a job is added (polling for a queue to add the job to.) The  
single queue seems simpler in that regard, but introduces contention  
for the single job queue, and a bit of randomness about which threads  
will get access to the queue.

Erik.


On Jul 13, 2006, at 12:19 PM, David L. Rager wrote:

> Hello Erik,
>
> We have an application that does exactly this, recycle threads.   
> Well not
> formally "recycle", but we prevent the threads from dying and then  
> they grab
> more work when it's available.  If you want threads to expire after  
> they've
> waited 60 seconds for work, you should consider timed-wait-on- 
> semaphore
> instead of wait-on-semaphore.
>
>>> My first attempt at getting this to work relied on preventing the
>>> threads from going dead (exhausted) by resetting them just before  
>>> the
>>> thread's function exits (basically the thread runs an anonymous
>>> function whose job is to wrap the target function so that it doesn't
>>> exit with errors.). I think I found that exhausted threads could
>>> sometimes be reused and sometimes not, but the docs say not to do  
>>> this.
>
> Sounds a complicated.
>
>>> Or perhaps I'm going about this wrong -- the thread could run a
>>> function whose job is to just wait (i.e. on a semaphore.) for a
>>> function to be provided to it (i.e. setting some variables or  
>>> slots),
>>> then run that function, then when it is done re-enter the wait loop.
>
>>
>> I think that that's what I'd recommend;  PRESET/RESET involve some
>> handshaking and synchronization.
>
> I agree with Gary.  This is what we do.  I think you get the  
> benefit of
> knowing that each piece of work is large enough to warrant spawning  
> off.
> Therefore, you can have a pretty straightforward implementation.
>
> David
>
>