Re: Safety-critical development in Ada and Eiffel

[Ken Garlington <kennieg@flash.net>]

Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> Ken Garlington wrote:
> :>
> :> :I responded elsewhere in this thread about difficulties in trying
> :> :to accurately measure thread timings at the object level,
> :>
> :> As I've already explained, SCOOP *does* support thread-level timing. The fact
> :> this has not yet been tested in a realtime system doesn't invalidate any
> :> logical arguments made about it.
> :
> :No, but then again, saying "X *does* support thread-level timing" isn't
> :a
> :logical argument, it's an assertion. And assertions, in the absence of
> :any experience (either general experience from the author, or specific
> :experience with X in a real system) are not particularly useful.
> 
> Not at all. It's more than an assertion - it's a fact. You may choose to
> disbelieve that fact for whatever reason but that doesn't alter its truth.

I hadn't realized we were dealing in terms of a "higher truth" that
doesn't
require argument or evidence. I never argue religion, so we'll have to
just
disagree on this one.

> 
> :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. 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?

I have a feeling that we're just not communicating on this issue. My
experience is in real-time systems, and I think I'm just not
properly conveying the issues involved in developing those systems.

> 1) and 2) can be included.
> 
> :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.

Once I see an appeal to authority, I pretty much have to assume the
discussion is over. We'll just have to agree to disagree on this as
well.

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