Re: Safety-critical development in Ada and Eiffel

[donh@syd.csa.com.au (Don Harrison)]

I wrote:

::>... There is a complementary
::> library mechanism called "express messages" which allows pre-emption of threads.
::
::Perhaps this "express messages" is the backdoor which I have to believe
::a real system would need.
:
:Correct.
:
::Correct me if I'm wrong, but no other thread can run while do_something is
::executing? 
:
:On a single processor, yes. On a multiple processor, no.
:
::Or are you saying it can be interrupted, just that no other thread
::can access the objects referenced in the parameter list (or any objects
::referenced in _their_ parameter lists? )?
:
:Correct.

I need to clarify this. Unless the default duelling status of the objects 
involved changes as a result of calls to class CONCURRENCY (retain, yield,
wait_turn, demand, insist), a thread will not be interrupted and (in theory)
no other thread can access the objects in the parameter list of the operation
being called.


On protected types:

Ken Garlington wrote:
 
:> ::can requeue requests,
:> 
:> I wrote:
:> ... The problem in Ada which "requeue" is designed to deal
:> with doesn't arise in SCOOP because successive calls to the same separate
:> object are atomic. That is, the object doesn't get unlocked between calls.

This means that, under SCOOP, locking is operation-based rather than 
object-based. Protected types, in contrast, have object-based locking. This 
means that a calling thread issuing two consecutive calls to a protected 
object cannot be guaranteed that no other thread will update the protected 
object between the calls. 

If I understand correctly, requeues are a means of getting around this problem
by allowing the callee (the protected object)  to issue extra calls (on behalf 
of the calling thread) while it is still locked. I think this scheme is 
deficient for a couple of reasons:

1) It doesn't fix the underlying problem - the lack of atomicity inherent in
   object-based locking. As such, it's a workaround rather than a mechanism 
   that should exist in its own right.

2) It's undesirable from a modelling perspective:

   a) It's incorrect for a caller to be making calls to itself *on behalf 
      of the caller*.

   b) It introduces undesirable interdependencies between entries - for example,
      the blocking abstraction on P. 9-16 of the Ada95 Rationale. 

      Under SCOOP, inherently autonomous operations remain autonomous in 
      accordance with sound design (read "OO principles").

One thing I'm curious about is where the requeued call gets placed on the 
entry queue. I guess it must be placed on the head, rather than the tail, 
for this to work. Is that the case?


:True. However, the question still stands: What happens if a thread attempts to
:access a locked (or otherwise unavailable) resource? 

It gets queued in the queue of callers for that object (one queue per object).
Out of interest, is there one queue per protected object or one queue per entry?

:I can use requeue in these situations; 

Sorry, don't see what you mean. As far as I can see, requeue is used by the
thread that has control of the protected object, not a thread that's trying 
to get hold of it.

what do you do?

The controlling thread doesn't have to worry about it because it retains control
of the separate object even when individual calls to it have completed. The 
separate object only gets unlocked when the calling operation itself completes.


:> For example,
:> 
:>   do_something (a: separate A) is
:>   do
:>     a.do_x
:>     a.do_y
:>   end
:> 
:> does exactly what we expect. There is no need for do_x to "requeue" do_y.
:
:That's not how requeue works, as I understand it. The issue is more: you
:attempt to do a.do_x, and someone else has already seized the resource, or
:there is some other time-based reason why a.do_x is unavailable.

What you've described sounds more like the mechanism for queuing calls. Requeue 
is something different, as I understand it.


:> 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).
:
:It depends. A "requeue" may be needed because of the state of the
:object, and may not be related to the state of do_something.

In that case, do_somthing need only test the state of the separate object 
and take whatever action is necessary - calling another operation in it,
for example.

   do_something (a: separate A) is
   do
     a.do_x
     if a.some_condition then
       a.do_y
     end
   end


:> :If anything, "requeue" probably encourages poor design.
:> 
:> .. as I've just explained.
:
:Sorry, don't see it.
:
:I think you would need to apply SCOOP to some fairly complex
:real-time systems to see the problems I'm discussing. 

I think I've addressed all the issues you were concerned about. From a 
theoretical standpoint, SCOOP should work and should be scaleable. Of course, 
it will be reassuring to have the theory vindicated by seeing it applied 
successfully to a significant-sized project.

:So long as all the objects have short lifetimes, and no priority issues
:are around, I would assume it seems to work fine for simple systems.

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).


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