RE: [boost] Future of threads (III)

From: scott (scottw_at_[hidden])
Date: 2004-02-15 20:26:37

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Jeff Garland
> Sent: Friday, February 13, 2004 3:58 PM
> To: Boost mailing list
> Subject: RE: [boost] Future of threads (III)

> > > This reminds me of the actor model of distributed 
> > > computation. If you are 
> > > familiar with actors, could you briefly compare/contrast your 
> > > approach 
> > > against them?
> > 
> > i know of uml's actor but not sure if that's the same thing.
> > and my knowledge of uml is so lame i suspect i shouldnt attempt
> > any analogies.
> 
> I believe you'all are talking about 'Active Objects'.  Doug 
> Schmidt, primary
> author of ACE, has written extensively on this subject.  Take 
> a look at this
> paper:
> 
> http://citeseer.nj.nec.com/lavender96active.html
> 

Thanks. AOs have a significant number of similarities with the
model that I have been working with; e.g. scheduler, servant.

There are also some differences. Some of these can be considered
implementation specifics while others are differences in design goal
or underlying paradigm.

Method Request is the object sent by a client, queued in a
scheduler and performed within a servant. The AO pattern defines
a request+results model, i.e. an asynchronous modeling of the
traditional synchronous call (arguments = requests, results =
return value). The pattern does allow for deviation from this
model with one-way methods.

For several reasons I have found this "unsuitable". Firstly the
adoption of "method" as part of the vocabulary is unfortunate (at
least, according to me :-) It brings with it "synchronous baggage".
A strange symptom that I have encountered is a difficulty in
separating client code from server code, i.e. clients sometimes
include a quantity of inert and redundant server code.

Also, the interaction with servants tends to involve more than
a single exchange (request+result). A much more flexible model
can be built on a "send" primitive (i.e. from SDL) which achieves
something very similar to the internal workings of AO "methods".
This breaks away from the Q+A model, allowing for "one-way",
"two-way" or "any-old-way". The relative "looseness" of send vs
method can be too much for some.

It could be argued that a one-way method allows for all of this.
As long as that facillity is buried within the larger method-based
document then I think it is too effectively mis-represented.

The "method-based" thinking also results in C++ classes with
methods that translate to each of the messages that might be
sent. In my book this is tantamount to the servant claiming
ownership of the protocol. I'll skip the tedious explanation
of that one and just say "i really struggle with that one".

There is some notion of "a main application" and servants or
schedulers that might be available. I question why there is a
distinction. The transfer of a Method Request to a servant is
so similar to the transfer of results back; to not use the
same technique seems almost tragic. I have applied the alternate
model into existing frameworks and been pleasantly surprised,
i.e. it was easy to present "theApp" (MFC/AFX) as a scheduler.

A difficulty inherent in "breaking away" (from the method model)
are the objects that are exchanged (previously "Method Requests").
In the new model these objects have some very interesting (i.e.
painful) requirements. I'll skip another long explanation for a
time when someone actually wants it :-)

Thanks again for the reference. It is material I definitely
needed to cover. I think it was very close but did have different
goals.

Cheers,
Scott