[mailto:boost-bounces@lists.boost.org]On Behalf Of Peter Dimov
DG mentioned boost::threads. And you guys kinda sorted out how to make an object equivalent to a thread (using boost::threads)?
Not really, no. An object can never be equivalent to a thread. These are two separate concepts.
yes. my misuse of the word "equivalent".
You can kinda tie the lifetime of a thread with the lifetime of the object and make the one accessible from the other, but that doesn't make them equivalent; they are still separate entities held together by duct tape. And once you reach a certain complexity threshold the "a thread is an object" pattern will limit your options.
hmmmm. ultimately agree with this; no-one wants to maintain a 300-thread system and no platform wants to run it (presenting a position here rather than being technically accurate :-) that being so the ActiveObject pattern does not prescribe a thread per object. the pattern defines schedulers and servants. there is a (platform) thread per scheduler and any number of servants related to that scheduler. i am guessing that the "active object" referred to in recent messages, best maps to "servant". this model might seem unnecessarily complex or a knee-jerk response to the issue you raise (a thread per object is not scalable). it certainly addresses this issue but intentionally or otherwise, it also resolves quite distinct concurrency issues. i tried to present an example of this in a previous message but its not easy, i.e. its stressing my ability to articulate. typical code from a multi-threaded development follows certain lines as a response to concurrency. classes are developed that are basically message processing threads and other classes are developed that encapsulate certain function and are synchronously called by the message processing class/thread. the latter can ignore concurrency if it is only accessed indirectly via the former. the ActiveObject pattern overlays nicely onto this "typical code". so when we refer to an "active object" or "inherited thread" its not (technically) anything from the pattern. it does closely resemble a servant. and a servant does not consume a platform thread. i believe that what everyone intuitively wants is the same (or very close) and that it is fulfilled by the definition of a servant. if that is so, then the number-of-threads issue is obviated. with a vague hope that it helps, the implementation that i am working with has two significant base classes, lets say "scheduler_base" and "servant_base". the "real" scheduler is a template with policy parameters for thread creation, message queue definition and processing. the template inherits from the base (of course :-). an active object would (most often) be derived from "servant_base". lastly, scheduler_base inherits from servant_base, i.e. scheduler is-a servant. a relationship missing from the original pattern. in my opinion. there seems to be some interest but not sure where everyone wants this to go? there was some excellent code from matt and a whole lot of quality discussion. this works for me :-) but tangible output is always nice. cheers, scott ps: now that i have converted a decent amount of code to active objects the result reminds me of doctor dolittle; its like talking to the instances ;-)