RE: [boost] Re: [Threads] Simple active object wrapper, take 2

From: scott (scottw_at_[hidden])
Date: 2004-02-22 16:44:00

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt
> Sent: Friday, February 20, 2004 4:46 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: [Threads] Simple active object wrapper, take 2
>
>
> scott <scottw <at> qbik.com> writes:
>
> > only one item of feedback really. think that i follow your
> > machinery and can envisage the "model of execution" - its
> > pretty slick. its also somewhat different to the pattern
> >
>
> Really?  I think it corresponds fairly closely to the pattern
> described
> in the paper by Lavender and Schmidt; it's a limited form of
> the *potential*
> pattern, in that it enforces a single execution thread for the active

yes. quite true.

apologies for the previous bluntness. my only justification is that i can
see a very useful chunk missing and my inability to articulate this is
making even me laugh. and i am also having difficulty with my "shift" key...

This message is a response to all relevant messages through to your response
of Saturday 21st.

In my opinion, the ActiveObject pattern can be divided into two operational
aspects. One is where a "main thread" has one or more ActiveObjects
available
to it and the other is where ActiveObjects interact with each other.

If these operational architectures were referred to as asymmetric and
symmetric
activation, respectively, then my goals with respect to implementation of
the pattern are focused on "symmetric activation".

Distinguishing these two architectures I feel, is crucial. Your latest
implementation code includes "futures" _and_ "method requests". I
acknowledge
this (again :-). But there is no mechansim for the results of a "method
request" to be returned _asynchronously_. For this reason I (and I am open
to explanations of why I am wrong) view your implementation to be in the
direction of asymmetric activation (AA).

To highlight the significance of this target (i.e. AA) I will return to the
database server example that several contributors have made reference to.

Lets say that the database server is most effective as a threaded,
ActiveObject. Lets also say that due to the architecture of the underlying
interface to an RDBMS, there are significant throughput gains to be
made with 4 slave threads. If a GUI app is the "main thread", the database
server is a threaded, ActiveObject and the slaves are threaded,
ActiveObjects
(all examples of AA) then the result is non-optimal. It would not realise
the advertised benefits of 4 slave threads as the database server must block
waiting for completion of a slave method (e.g. evaluation of a future).

A cruder example of what I am trying to highlight is where a group of
interacting ActiveObjects manage to create a "circular activation", i.e.
A calls B, B calls C and C calls A. This is a fatal symptom of the
underlying
problem associated with AA.

I immediately concede that you may implement some sophisticated "event
notification" between the database server and its slaves to solve this.
You may even choose to not implement the slaves as ActiveObjects to give
yourself the necessary "freedom".

My response to this would be that the custom event notification is
completely
unnecessary. Application of an SA-focused ActiveObject removes the need for
any such one-off mechanisms (and who wants to write those again, and
again...).
Finally, having deployed (SA) ActiveObjects I would be disappointed to see
any new mechanism for thread communication. Proof of a successful
implementation
of SA (IMHO) would be that it became the _only_ mechansim for inter-thread
communication. Of course, in the real world, this is not going to happen but
I would offer it as a noble intent :-)

I tentatively suggest that the ActiveObject that most of us want is the AA
variety.
We can see the objects exchanging the Method Requests in a symphony of
optimal
operation - in our heads. But between our heads and the "tools at hand" I
believe
the symphony becomes something else, primarily due to AA-based environments
and
associated culture.

Having made my case (as best I can) things now get muddy. Firstly I dont
see any mechansim for the delivery of asynchronous results in the pattern!
Please
note that I wanted to verify this claim but have failed to connect to
siteseer
for the last two hours. In my ActiveWorld the same mechansim that is used to
queue Method Requests (in your implementation - "tasks") is also used to
queue
results.

While I can see the pragmatic value in including both AA and SA in all
ActiveObject initiatives, I also wonder about the psychology of developers.
While implementation of SA ActiveObjects is a little bit more difficult I
suspect there are other reasons that it doesnt "catch on". Firstly,
we tend to shy away from new, foreign models of execution and secondly AA is
always there to "fall back" on.

It might be interesting to note that my ActiveWorld implementation is
_completely_
SA. The very pleasant surprise for me has been the successful manner in
which
it has been deployed in existing codebases. It may appear foreign but our
best
coding is naturally trying to emulate the SA ActiveObject.

Cheers,
Scott

ps:
I mentioned the "anything declared in private scope is thread-safe" to see
if we were "on the same wavelength". After reading your response(s) I think
the answer to that is "yes". Or am I deluding myself ;-) Any _data_ declared
with private scope in the "struct object" would only be accessible to the
methods
of that same struct and those methods are only every called by
"boost::thread thread"
in "class active". Voila! We dont need any mutexes around that data!