Newbie: Clarification of non-determinsitcis selection in Ada rendevous Mechanism

Newbie: Clarification of non-determinsitcis selection in Ada rendevous Mechanism

[nootah]

Hi people,

Currently studying a course where Ada is referred to but not taught and have
a brief section on Active Objects using the Ada rendevous mechanism as an
example.

Question is: if the selection of action from a select clause is
non-deterministic, then does the active object pause at the select statement
or does it elect one of the processes to wait for - the altter is what I
have been told. My problem with this - if multiple guard conditions are
simultaneously true, and one is selected prior to any call, then what occurs
when one of the client processes calls another guarded func.

e.g. where a=5

    select
        when a>0 =>
            accept(FirstFunc)
        when a<10 =>
            accept(SecondFunc)
        end select
    end select

If object halts at select and waits for request from client
    what happens if func called and guard condition not fulfilled ? -
presumably client blocks until condition met and task can respond - queues
the request and blocks client

On the other hand, if object elects FirstFunc, but client SecondFunc is
first call received - what happens ? presumably .. I have no idea!

Any help gratefully  appeciated .
Cheers
Andy

Re: Newbie: Clarification of non-determinsitcis selection in Ada rendevous Mechanism

[Robert A Duff]

"nootah" <nootah@ihug.co.nz> writes:

> Question is: if the selection of action from a select clause is
> non-deterministic, then does the active object pause at the select statement
> or does it elect one of the processes to wait for - the altter is what I
> have been told.

No, that's wrong.  The task waits at the select statement.  Whatever
calling task comes in first gets accepted (assuming there are no guards,
or all guards are true).  The called task does not choose which one to
wait for when it doesn't know which one is going to happen!

The nondeterminism mainly comes into play when there are two or more
tasks already waiting in entry queues when the select statement is
reached.  In that case, a caller is selected nondeterministically,
according to the core RM semantics.  In the Real Time Annex, however,
the selection criteria are nailed down more tightly.

>... My problem with this - if multiple guard conditions are
> simultaneously true, and one is selected prior to any call, then what occurs
> when one of the client processes calls another guarded func.

Good point -- that rule wouldn't work very well.  Luckily, that's not
the rule.  ;-)

> e.g. where a=5
> 
>     select
>         when a>0 =>
>             accept(FirstFunc)
>         when a<10 =>
>             accept(SecondFunc)
>         end select
>     end select
> 
> If object halts at select and waits for request from client
>     what happens if func called and guard condition not fulfilled ? -
> presumably client blocks until condition met and task can respond - queues
> the request and blocks client

Right.  (That's not the above example -- in the above example, both
guards are True.)

> On the other hand, if object elects FirstFunc, but client SecondFunc is
> first call received - what happens ? presumably .. I have no idea!

The task does not elect FirstFunc unless and until there's a caller for
FirstFunc.

- Bob

Re: Newbie: Clarification of non-determinsitcis selection in Ada rendevous Mechanism

[Ted Dennison]

In article <wccg0rh1eyn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> The nondeterminism mainly comes into play when there are two or more
> tasks already waiting in entry queues when the select statement is
> reached.  In that case, a caller is selected nondeterministically,
> according to the core RM semantics.  In the Real Time Annex, however,
> the selection criteria are nailed down more tightly.

To be more specific, on two *different* entry queues. If multiple tasks
are waiting on the *same* entry, they are accepted FIFO. If FIFO isn't
flexible enough for you, you can implement other schemes using the
requeue statement.


I'll attempt to clarify. When a task or guarded object gets to a select
statement it first evaluates the guards on the alternatives. If some are
true, then there are two possible situations; either there are tasks
already waiting on one or more entries, or there aren't any waiting. If
there aren't any tasks waiting on any entry, it will wait for a task to
request (any) one of them. It will accept the first one that comes in.

If there are already tasks waiting for only one entry, it will
immediately process the first task waiting on that entry. If there are
already tasks waiting for *more* than one open entry, *then* it will
non-determinsticly choose which entry to accept.

Note that the guards are only evaluated right before the waiting starts.
If one changes while the task/object is waiting, that does not change
the entries that it waits on.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.