Boost logo

Boost :

From: Sean Kelly (sean_at_[hidden])
Date: 2004-02-17 01:21:34

scott wrote:
> I am assuming that the code that is presented for execution is
> some kind of message queue processing and that that processing
> results in calls to a method or methods in the "thread derived"
> class? Something like this needs to happen (I think) if there is
> going to be a class that has the appearance of running as an
> independent thread.

I agree. The object model has always made more sense to me in this case
as the thread and executing object code seem tightly bound. I do
sometimes use a "job queue" however, that's sort of a fancy thread pool
which uses job objects much like the Boost design. This was really
designed for short-term or fire-and-forget tasks however.

> I think that the concept of "class that is a thread" is a
> compelling one. The Active Object pattern is a pretty damn
> good formalization of what many people would tacitly understand
> the concept to be.

If a person is creating an object that is going to be executed as a
thread, he must do so deliberately. Synchronization points must be
considered, etc. To me, the inheritance model more accurately
communicates the purpose of such a design than does the Boost model.
but it also assumes that the object *is* a thread rather than that it
can be used in an asynchronous fashion. I think there are definite
applications for both designs.

> An AO is something that comes into existence, certain events
> are directed to it and it responds to them. This describes an
> object that receives "work to do" over time. Work is not submitted
> (in fact, cannot be) at ctor time.

Another model that suits this design is a pool of anonymous worker
threads, though it's perhaps conceptually a bit less obvious. With that
model, you have a bunch of threads that pull tasks of a job queue and
process them. State information is stored as part of the message or by
some other means. IOCP is a perfect example of this.

> Do you guys have any thoughts on how to "get work into" the
> class (now that it is truly a running thread)? Cos this is
> the essence of what an AO is. I think :-)

Depends on the application, I suppose :) I wrote a comm. framework a
few years ago that makes fairly heavy use of proxy objects and
callbacks. Some other applications may be simpler and just expose
methods directly on the subclassed thread object.


Boost list run by bdawes at, gregod at, cpdaniel at, john at