Re: Combining entry_call, accept_statment and terminate_statment

["Robert I. Eachus" <rieachus@comcast.net>]

Mark Lorenzen wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> [cut]
> 
> 
>>But I'd say that you probably have a design problem if you have a task that
>>is both calling and accepting at the same time. That's pretty weird (unless
>>the accepts are purely for task control, as above). It's preferable that
>>each task be either a server (accepting entries) or a client (calling
>>entries), but not both. Analysis is complicated if you have both.
>>
>>                      Randy.
> 
> 
> To me, this seems to be a severe design limitation. Isn't it normal to
> have a task acting as a filter, i.e. reading data from a PO,
> manipulating the data and the writing the manipulated data to a PO?
> This could f.x. be a task implementing a (de)multiplexer.
> 
> - Mark Lorenzen

I was going to say that the special case of a "transformer" that accepts 
a call and then immediately makes a call, usually in a loop is an 
exception to this rule.  But you beat me to it.

If you create a call graph for tasks and protected objects each node 
should either make calls or be the target of calls, with this one 
exception where the net number of calls is always negative.  If you want 
to think of these special cases as arcs instead of nodes, that works too.

Oh, and there is a different exception which is seldom used.  You may 
requeue a call to you as a call to a different entry (common) or to an 
entry of another task.  I have no idea of how to represent or analyze 
that last case.

-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney