Re: Safety-critical development in Ada and Eiffel

[Ken Garlington <kennieg@flash.net>]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> 
> So, how does the runtime system select which queue to take the next call from?
> Is it arbitrary? ..or the one for the first declared entry? ..something else?

See http://www.adahome.com/rm95/rm9x-09-05-03.html para (17):

"If calls from two or more queues are simultaneously eligible for
selection,
the default entry queuing policy does not specify which queue is
serviced first.
Other entry queuing policies can be specified by pragmas (see D.4)."

> I think entries, by default, should be serviced in the order in which they
> are received by the object - which implies object-based, rather than entry-based
> queueing. This is how SCOOP works.

If you prefer this, you can use Priority_Queuing as described in D.4, or
just
provide a single entry to the object (with a parameter denoting what
needs to
be done). The extra flexibility of multiple queues lets you provide
different
entries for different priorities, so that you can take calls "out of
order"
based on some policy.

> 
> :.. any entry can be requeued. Furthermore, it's not up to the caller or callee,
> :it's up to the protected object:
> 
> The callee *is* the protected object. What do you mean by callee?

I meant to say "either caller" - the two tasks that would be dueling in
SCOOP.

> :"A requeue_statement can be used to complete an accept_statement or entry_body,
> :while redirecting the corresponding entry call to a new (or the same) entry
> :queue. Such a requeue can be performed with or without allowing an
> :intermediate cancellation of the call, due to an abort or the expiration
> :of a delay."
> :
> :"A requeue_statement shall be within a callable construct that is either an
> :entry_body or an accept_statement, and this construct shall be the innermost
> :enclosing body or callable construct."
> :
> :Again, the internal timing/sequence requirements can be hidden within the
> :object. It makes the decisions based on its internal state, ..
> 
> Seems okay.
> 
> :> :> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely
> :> :> locking at the object level. Further, it's a *deficient* workaround because
> :> :> supplier objects are forced to do things (do_y) that should be the
> :> :> responsibility of clients (do_something).
> 
> I think I probably misunderstood requeue's purpose here. The criticism of
> object-level locking reamains valid, though.

If you say so...

> 
> :> I think it will be fine for *any* size system. Obviously, it will require a
> :> different design approach to that used with Ada because of some fundamental
> :> differences. These differences make it both more restrictive (in reliability-
> :> enhancing ways) and less restrictive (in ways that enhance reuse and modelling
> :> integrity).
> :
> :The design approaches I describe didn't come with Ada. They've been around
> :since assembly days. The same issues are described in real-time courses
> :regardless of implementation language.
> :
> :It would be interested to take some examples from these courses, such as the
> :HAS Buoy, Cruise Control, and ATD/CWM case studies from the ADARTS material,
> :and have them coded in SCOOP and executed.
> 
> I agree - it would. If I get a chance, I'll take a look. Where are they?

See http://www.software.org for more information.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au