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

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-27 20:02:38

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

> At the point where the scheduler is holding the result of type
> int, it needs to be able to "deliver" it to the caller. The only
> way it can do this is call a method on the appropriate object
> (instance) passing the results. Which method and which object?
> The scheduler can only get these from the queued task, i.e.
> the task must hold the method-to-run and pointers necessary for
> the return delivery.
> 
> This method will be another proxy (e.g. non_void_with_param_returned)
> that in turn, queues the result. This decouples the scheduler from the
> recipient of the results; eventually the thread working on that
> task list will reach the "results task" and will run that.
> 

So you have a callback, the invocation of which queues a message?

> How does the object and method address get in the task object?
> You may well ask and this was (some of) the reason for my
> initial response.
> 
> A by-product of working on "active objects" is a set of
> classes/templates that constitute a little thread-toolkit. This
> toolkit should facillitate the design and implementation of
> pretty much any snarling, thread-beast; if that is what you need.
> 
> The "damn" part of my response stems from the fact that I
> believe the "Method Request" model is not viable as a model
> of execution for the thread toolkit. It is simply wrong and
> bending it to this task is a deadend.
> 

I don't understand why you think this.  I think the active object wrapper
indicates that you can use the method request model to encapsulate the 
interactions between the threads.  There's no reason why it can't be the
interface layer on top of a message passing system, provided that the
result does yield simpler interfaces.

> In signal processing the equivalent to "Method Request" is
> "send". This primitive takes an object to send and the
> address of the destination (e.g. an active<object>);
> 
> 	send( int_results, calling_object )
> 
> These calls are made from within the methods that you
> already have working, i.e. the non-proxy _real_ methods.
> 
> The trick with "send" is that it can be coded to
> populate the "task" with all the appropriate object
> and member pointers so that the receiving thread
> knows where it came from. Pretty typical SDL

What is SDL? I parse it a Simple Directmedia Library...

> classes will look like;
> 
<snipped>
>
> I really hope this helps because I can see the inductive
> leap required to get over the chasm of despair.
> 

Yes, this demonstrates what you're doing quite clearly.  But, it also 
demonstrates the weakness that the logic is switch-based, which is kind of
what C++ was invented to circumvent...

If you can bind the code-to-be-excuted to the content of the message, then the
need to inspect the message and make a decision is removed, and this is an
advantage you could derive from a method request model.

I do now understand your separation of threads from objects.

> I only have one more esoteric observation to make. The "Method
> Request" model of execution is nice and familiar to us. It works
> brilliantly - mostly. Return addresses are managed automagically
> for us. But return addresses on a CPU stack are pretty meaningless
> when it comes to inter-thread communication. With the "Method
> Request" model we are trying to "call" across thread boundaries -
> IMHO thats just wrong.
> 

I can't agree with this.  The proxy objects in the active object wrapper 
demonstrate one way to pass call information between threads - I don't see why
the return information cannot be managed in the same way...  Of course, you
can't return to an arbitrary place in the execution - method addressses
would have to be used.

> With a bunch more scaffolding this is what my reactive_object
> code looks like;
> 
> 	int
> 	db_interface::transition( machine_state<READY>, typed_bind<interface_open>
> & )
> 	{
> 		client.insert( sender() );
> 
> 		send( status, sender() );
> 
> 		return READY;
> 	}

This seems very nice, although it seems to be more about the state machine
code than the communicating objects.

> Apologies if this is all badly presented. I have a huge body of code
> from which the ActiveObject portion would be impossible to remove. A major
> reason for starting or contributing to this thread is that I think my
> existing code desparately needs boostifying and the best way (or even
> a good way) is beyond me. Hence our messages.
> 

I understnad what you're doing now.  What are the drawbacks you want to 
address in your code?

> Cheers,
> Scott
> 
> ps:
> the sample code from mark blewett looks very promising?
> 

Yes.  Although from my point of view, it has the same drawback with switching
on messages that you have.  I wonder if the queue of messages in the servant
class could be a queue of fully-bound function calls, generated by proxy
objects which describe interfaces?  (Yes, I am quite enamoured of that
idea :))

Matt.