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