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

From: scott (scottw_at_[hidden])
Date: 2004-02-17 14:29:52

> [mailto:boost-bounces_at_[hidden]]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 ;-)