On Monday 11 January 2010 13:27:05 Markus Klotzbuecher wrote:
> On Mon, Jan 11, 2010 at 11:32:07AM +0100, Peter Soetens wrote:
> > I'm pick-axing through the new method call/send/collect implementation.
> > I'll resume shortly what this is about. When your component implements a
> > function (aka service or operation) it can indicate if it has to be
> > executed in the clients thread (old method behavior) or its own thread
> > (old command behavior).
>
> What exactly is done with this information? Is used to limit the
> "modes" in which the operation is allowed to be used?

Not at all. The operation can be used in all cases (send/call). It is used to
choose an implementation that relays the client call to the actual function.

>
> > This is a decision the component writers keeps for himself, the caller of
> > this function can not see this difference, and multiple components may
> > choose differently. What the caller can decide is that when he invokes
> > such an operation, to do this synchronously or asynchronously. This
> > translates to these two cases:
>
> So if I execute and operation and the offering Component has indicated
> it can not be executed in this mode, the call fails?

No. it's not a restriction, it's a policy. When the component indicates
'client thread', call() will relay directly to the operation's function. If
the component states 'own thread', call() will boil down to an internal send()
and a collect(). In the case of 'client thread' and send(), a third thread
needs to be assigned that will execute the operation on behalf of the
component.

>
> >

> > // user of component function 'setParam':
> > Method<Result(double)> setParam = ... ;
> > // block for result, which is a user type:
> > Result result = setParam.call(3.0); // may be abbrev. to setParam(3.0)
> >
> > // do not block:
> > Result result2;
> > SendHandle<Result(double)> handle;
> > handle = setParam.send(3.0);
> >
> > // some time later, collect the return value:
> > SendStatus ss1 = handle.collect( result2 ); // blocks
> > // or:
> > SendStatus ss2 = handle.collectIfDone( result2 ); // polls.
> > // a third variant with a timeout is possible too:
> > SendStatus ss2 = handle.collect_timed( result2, timeout );//blocks w/
> > timeout 

> > // one callback function for all calls to the method:
> > setParam.callback( &function );
> > setParam.send( 3.0 );
> > // function(Result r) will be called when setParam completed.
> > 

The callback is very likely to be a boost::function object which can store any
callable, not just a C function. We can add overloads or utility functions
that convert some generic functor into boost::function.

>
> > While this is a simple and may I say, intuitive, API, the implementation
> > requires way more from the OS in comparison to the 1.x functionality we
> > offer. More specifically, for in-process communication, we require
> > condition variables to implement call(), collect() and collect_timed().
> > There will be one condition variable and one mutex for each
> > ExecutionEngine to mediate the race conditions that may occur when
> > concurrently calling collect() while executing the component's operation
> > that was 'send'.
> >
> > LXRT, Xenomai, GNU/Linux support this, Windows XP/2003 seems not to, but
> > the boost::thread library seems to have a way to work around that, since
> > it offers condition variables on Windows too.
> >
> > An OS that does not support condition variables would allow applications
> > only to call send(), collectIfDone() and callback() in case of
> > asynchronous operations. call(), collect() and collect_timed() could be
> > 'emulated' by a periodically polling implementation though.
> >
> > I didn't forsee this requirement when proposing the above API. I think
> > the API justifies such a requirement on the RTOS, but I wanted to give
> > any opposing views the opportunity to speak before settings things in
> > stone.
>
> So all currently supported OS either offer the functionality or you
> have an workaround. So where's the problem? Or do have you a
> particular not-yet-supported OS in mind which has condition variables?

I didn't check ecos, and can't tell for users using in-house developed
rtos'es.

Peter