RE: [Boost-users] boost::threads: howto organize them ?

From: Pete (petehug_at_[hidden])
Date: 2004-12-12 22:59:07

I have implemented my own thread class based on boost::threads almost
two years ago and it does all the things that you guys are talking about
here. Initially I attempted to implemented this using
boost::threadgroups but I soon relised that boost::threadgroups was more
or less unusable (in boost 1.30.0). 

My abstract Thread class runs under Windows, Linux (RH9) and HP-UX. Some
of the features the class implements:

- parent, child and dependent threads (or any combination of these)
- framework supports pause/resume/stop requests and these requests are
automatically propagated to child threads
- timer threads
- notify message which allows you to send customised events to a thread

The downside is:

- I don't have a lightweight example and the class suits my project
- Documentation - what documentation? :(
- There is quite a bit of overhead per thread object

If anyone is interested, I'm happy to provide the code, just send an
e-mail. I'd be interested to have a look at your code Martin if you
don't mind.

Pete

> > Hi Boost::Thread users (developers)
> >
> > During the past months I had to create a portable thread management 
> > shell around boost::threads to allow a simple thread management.
> >
> > The idea was to (implicitly) put each thread into a hierarchy (just
> > like forked processes but with more features than 
> boost::threadgroup
> > offers). These threads now share a global structure to allow global
> > access to their control
> > interface (mainly a 'stop!' flag).
> > Additionally I wanted to make threads requested to stop 
> (triggered by
> > themselves or from outside)
> > implicitly stop their children and finally remove
> themselves from the
> > thread management structures.
> >
> > It took me some time to make this approach a stable implementation
> > (would have been much easier if boost::threads exposed 
> their internal
> > and platform-specific id).
> >
> > I think the idea of hierarchially organized threads is quite common 
> > and wonder how it could be
> > *elegantly* designed using boost::threads.
> >
> Interestingly this question pops up rather seldom. Nevertheless I've 
> run into a similar proplem also related to graceful stopping a thread,

> which I am currently working on. Remarkably a question posted to 
> c.p.threads about examples or advices of how to stop a thread 
> gracefully (using pthreads) got no answers at all. At least with boost

> threads there is nothing such as a "thread ID" concept, i.e. you 
> cannot (from another thread) control it by native means.
> N.B.: The thread* is not usable as an ID in this respect, 
> since there might be two different pointers refering to the 
> same thread. (at least in 
> principle)
> 
> I am considering two possible implementations:
> 1) pass a "control object" as parameter to the thread function.
> 2) derive a custom thread from boost::thread that exposes a control
>      function. (and store a pointer to it in TLS strorage, so
> that it can
>      be seen from inside the thread.)
> 
> Either way the main problem that needs to be solved is of how
> to control the lifetime of this control structure. Keep in 
> mind that the thread structure might have been deleted before 
> the thread ends. The opposite also is possible and thus has 
> to be considered as well.
> 
> The concepts needed are related to the problem of breaking
> out of threads that are currently blocked. I have heard from 
> Aaron, that he is about to propose a solution to this. 
> Perhaps the concepts he is suggesting can be used in this 
> broader context too?
> 
> Roland
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/bo> ost-users
> 
>