From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!hao!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!ucbvax!GWUVM.BITNET!MFELDMAN
From: MFELDMAN@GWUVM.BITNET (Mike Feldman)
Newsgroups: comp.lang.ada
Subject: Re: INFO-ADA Digest V88 - tasking again
Message-ID: <8802211800.AA22317@ajpo.sei.cmu.edu>
Date: 21 Feb 88 17:11:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

In response to Susan Flynn regarding my delay test: I think you are
correct that I've got an erroneous program here. I suppose it would've
been better to time-stamp all the messages from the 2 tasks and write
them to 2 separate files. The intention was to find an easy and obvious
way to show that in the runtime systems I tested, the high-priority
task was not waking up on time (or at all). I agree that writing the
shared variable (the screen or whatever) should've incorporated
synchronization, but of course that very synchronization would've
probably defeated the example. Your discussion of I/O issues (again)
was very instructive.

The end purpose of the example (and the rest of the discussion) has
served the purposes for which I, at least, intended it:

1. to highlight the fact that many people experienced in Ada
   including, apparently, some compiler vendors, are disagreeing with
   each other in good faith (or just plain baffled) about what is
   meant by the LRM in this critically important area;

2. to highlight the apparent weaknesses in the ACVC in testing this area
   which is apparently so "make-or-break" to some real-time people. I've

I used the word "illegal" instead of "non-conforming"; perhaps I'm being
too loose with my terminology but the idea is the same: in this area
particularly, we all have especially weak signals from the ACVC and the
validation process about just what we should expect from the tasking part
of an Ada runtime system.

I have heard it said (glibly to be sure) that "all Ada tasking programs are
erroneous" - but I believe the confusion here makes it imperative that
attention be sharply focused on this area so that we have a clear and
unambiguous statement regarding what the runtime system is expected to
do, so that we can write programs that we are certain are not erroneous.

One rule of thumb I agree with is that Ada tasks should _always_ do some
explicit synchronization now and then. A brief delay might do, if nothing
else - but if _all_ tasks don't do it, there's _still_ no guarantee,
priorities notwithstanding, that a sleeping task will ever wake up.
I will continue to make this assertion until the ACVC tests the intent
of the LRM and all implementations are known to conform!

Call it illegal, non-conforming, or whatever buzzword you like - there
is still confusion on the issue, and I think my tests prove it.