Re: [Boost-users] [Threads-devel] Idea for a boost::barrier::scoped_wait class

From: Tim Day (timday_at_[hidden])
Date: 2006-12-20 15:56:38

On Tue, 2006-12-19 at 10:40 -0500, Stuart A. Malone wrote:
> However, I don't think that join_all() is an option in this case,  
> because I need to be inside a Mac event loop in order to receive the  
> messages that will launch the additional threads.  Since join_all()  
> would block until the existing threads had completed, I would never  
> receive the events telling me that I needed to launch additional  
> threads.

[Diverting to boost-users because this regards boost-threads usage, not
development].

You might find the attached code interesting as an example of how things
could be structured.  The loop in main() spends most of it's time
blocked on a getc call (which would presumably correspond to some sort
of event pump in your app), but a separate thread (the "master") manages
a pool of worker threads (initially 1; another one is added each time
you hit return on the console).  Each thread runs for 10s printing '.'
every second then terminates; if the worker count reaches zero the
master terminates too.  To be concise the code uses volatile bools to
communicate state between threads; in any sort of real code these would
probably be mutex-protected structures or std::deques.  The real key to
the whole thing is the boost::condition, which allows the master thread
to notice both keypresses from main() and completing workers.  Note
there's no boost::barriers to be seen.

[Attached code compiles with 
gcc threadmaster.cpp -o threadmaster \
  -g -pthread -lboost_thread -lpthread
on Debian Sarge with appropriate boost packages installed].

Tim