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

[Martin Pasdzierny]

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.

Any suggestions are welcome !

Martin.

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Roland Schwarz]

Martin Pasdzierny wrote:

> 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

[Pete]

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