[Openmcl-devel] thread pool question
erik at adaptations.com
Thu Jul 13 20:45:31 UTC 2006
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.
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
> waited 60 seconds for work, you should consider timed-wait-on-
> 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
>>> 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
> 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
>>> 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
> Therefore, you can have a pretty straightforward implementation.
More information about the Openmcl-devel