Re: Safety-critical development in Ada and Eiffel

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

Ken asked for evidence that SCOOP supports thread-level timing.

Ken Garlington wrote:

:I hadn't realized we were dealing in terms of a "higher truth" that
:doesn't require argument or evidence. 

The evidence is in OOSC-2. I would leave it at that but I'll give an example 
because I may have been responsible for confusing you. :(  Sorry if that's the
case.

I might have said that locking in SCOOP occurs at the object level. Anyone 
familiar with protected types would immediately assume this means objects are 
locked one-at-a-time (whenever they're called). SCOOP is fundamentally different 
in that groups of objects are locked together. As I'll explain later, this 
is an important distinction.

Why are they collectively locked?
Answer: So that processing can be performed under known conditions without 
  interference from other threads (helping to avoid race conditions). Also,
  so that we know up-front that we have all the resources we needed (helping
  to avoid deadlock).

When are they collectively locked? 
Answer: When they're supplied as parameters to an operation.

What if they're not supplied as parameters?
Answer: They always *are* (in the case of concurrent (separate) objects. 
  In the case of sequential (non-separate) object, we don't care because 
  we know they're local to the calling thread.

See the example below..

:> :Futhermore, here is a counter-argument to writing timing assertions
:> :at the object level:
:> :
:> :Using letters to denote objects, let's build a thread. The notation
:> :x{object}y means that the object is executed between x and y times.
:> :The arrows indicate that one object is executed before another object
:> :in the sequence. (For simplicity, we'll neglect objects calling
:> :objects).
:> :
:> :Thread: A -> B -> 1{C}4 -> D
:> :
:> :The max time for this thread is: A + B + 4*C + D, right?
:> :
:> :No!
:> :
:> :It also includes:
:> : 1. the entry/exit code for each object (4 times that, for C),
:> : 2. the time to start and stop the thread itself
:> : 3. Any time between object invocations "stolen" by other threads.
:> 
:> 3) doesn't apply to SCOOP because all objects are locked.
:
:(3) represents the time _in between_ object invocations. 

You might code your example in pseudo-SCOOP:

Assuming separate (allocated to different threads) entities

  my_p: separate P
  my_q: separate Q
  my_r: separate R
  my_s: separate S

and operation

  do_something (p: separate P; q: separate Q; r: separate R; s: separate S) is
  local
    start_time: time
    duration: ...
  do
    start_time := time_now
    p.a
    q.b
    loop (4 times)
      r.c
    end
    s.d
    duration := time_now - start_time
    ...
  end

the call

  do_something (my_p, my_q, my_r, my_s)

will do the required actions and measure the elapsed time.

Note that all four objects are locked for the block between "do" and "end".
This means that there is no intervening time between calls to them and there
is no opportunity for any other threads to jump in and make a mess of things.

Note that this offers more protection than Ada protected objects which are 
only locked on single object basis. As you will see later, this also removes 
the need for a "requeue" statement.


:If you are saying that a thread (a series of object invocations) cannot be
:interrupted at _any point_, then that pretty much eliminates
:concurrency, doesn't it?

No, it just means it's more controlled (and safer). There is a complementary 
library mechanism called "express messages" which allows pre-emption of threads.


:I have a feeling that we're just not communicating on this issue. 

True.

:My experience is in real-time systems, and I think I'm just not
:properly conveying the issues involved in developing those systems.

Likewise.

:> :If you start the measurement before the call to A, and stop it
:> :after the call to D, you only have to worry about #2 above
:> :(which is usually fixed). If you do the measurement at the object
:> :level, all three will skew your results.
:> 
:> Not true. If you really want to get a clue on this, I suggest you get hold
:> of OOSC-2 and read the chapter on concurrency.

Sorry, Ken. I was a bit rude here.



:Ken Garlington wrote (about Ada protected types):

::can requeue requests, 

I wrote:

:IMO, the situations in which you would use "requeue" are better handled by 
:designing differently - perhaps by using an additional class. 

Sorry, this is wrong. 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.
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.
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).

:If anything, "requeue" probably encourages poor design.

.. as I've just explained.



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