Re: [boost] Re: Re: Future of threads (III)

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.

Sean