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

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-23 22:13:47

scott <scottw <at> qbik.com> writes:

> > What is lacking is the ability to multiplex over events
> > relating to the
> > delivery of future values.  You can't use select, poll or
> > WFMO to determine
> > whether any of an outstanding set of futures have been
> > delivered.  I think
> > that this probably makes active objects an inappropriate
> > choice for designs
> > that are inherently reactive.
> 
> Yes, exactly. Is there no potential to leverage the mechanism
> you already have, i.e. "task"?
>

Yes, you can (if I now understand what you're asking correctly) - in the
parlance of the code we've been discussing, you can achieve this by having all
objects 'active' (with a thread), and having all functions as void functions
that produce flow-on effects to other objects.

Essentially, I send a message from my object to another object, and I receive
the result not as a return value, but as a new message from the other object.

But, as you point out later, we've now changed patterns.

The limitation resulting from the unequal status of different event mechanisms
is a fairly fundamental one.  Is anyone working on this in a boost threads 
context?

> It seems almost tragic that you have such a slick method of
> delivering "Method Requests" and that it cant be used to deliver
> "Method Results" asynchronously.
> 

There isn't any intention to have a slick method of result propagation; the
intention is to allow code which is not specialised for multi-threading to
seamlessly invoke code which will be performed in another thread.  Although
I understand what you're looking for.

> In another implementation this just involved storing some kind
> of "return address" and adding that to the queued object (task).
> On actual execution the thread (belonging to the active object)
> need only turn around and write the results back into the callers
> queue.
>

This implementation requires that all objects have a queue, which is another
property of the 'reactive object' system you're describing, but can't work
with the approach I've taken.

> The ActiveObject pattern was introduced early on and became a
> convenient vocabulary and point of reference. In truth it was
> never my target (I hadnt seen it previous to our discussion).
> It is totally impressive work but does duck a major nasty.
> 
> So, to hopefully clarify; I still feel there is a software abstraction
> that we (as developers) intuitively want. It is not completely
> delivered by the ActiveObject pattern (though I thank JG again for
> the reference).
> 
<snip>
> When I refer to asyn-res I am typically referring to the
> delivery of results from one active object to another, where
> the receiving object is not required to enter into a
> (potentially) blocking call (e.g. evaluation of a future).
> I have tried to label this circumstance as "symmetric activation".
> This can only occur between two active objects <cringe>.
>

Ok.  Having established that this is a different pattern of multithreading,
what are the costs/benefits of symmetric activation?
 
> > What interface are you using to allow active objects to access results
> > generated by other active objects?
> >
> 
> The short answer is; the same interface used to deliver Method Requests. The
> long answer would definitely be long. I can post some code fragments if we
> are still swimming after the same stick?
> 

Right; so all objects (even non-threaded ones) contain a task queue? (Or, 
perhaps 'interaction queue'?)  
When a request is queued to a non-threaded object, how does that request
get processed?

> Its been fun up to this point but perhaps your "code with legs" is
> viable as "active object" and that is a valid first phase? I could
> wheel my barrow off to the side for a while 
> 
> Cheers,
> Scott

Yes, I don't think my code can be modified to incorporate your requirements.
I am interested in your pattern, though.  

Perhaps a change of subject is in order?

Matt