[Openmcl-devel] thread pool question

[David L. Rager]

Hi Erik,

Sorry if I confused you, but I'm not sure where the idea for part A came
from.

You part B approach sounds right.  As you suggest, I wouldn't make a
dedicated master thread.

David

> -----Original Message-----
> From: Erik Pearson [mailto:erik at adaptations.com]
> Sent: Thursday, July 13, 2006 3:46 PM
> To: David L. Rager
> Cc: 'Gary Byers'; openmcl-devel at clozure.com
> Subject: Re: [Openmcl-devel] thread pool question
> 
> 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
> >
> >