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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!decwrl!hplabs!motsj1!mcdchg!clyde!rds@moss.ATT.COM
From: rds@moss.ATT.COM
Newsgroups: comp.lang.ada
Subject: Telegen Ada guard evaluation
Message-ID: <27110@clyde.ATT.COM>
Date: 26 May 88 17:57:27 GMT
Sender: nuucp@clyde.ATT.COM
Reply-To: rds@clyde.ATT.COM (Richard DeSimine)
Organization: AT&T Bell Laboratories, Whippany NJ
List-Id: <comp.lang.ada>

>From Dave Stein...

Our programs have
many concurrent tasks, and it seems that the TeleGen compiler is way
faulty.  For one thing, it seems that guards (i.e. when statements)
on accept statements simply do not get evaluated sometimes.

I enclose a short sample program.

...
	    select
		when (x > 10) =>
		    accept maybe do
			put_line ("we made it");
		    end;
		    exit;
	    or				-- XXX
                delay 1.0;
		x := x + 1;
		put_line ("can't accept yet");
	    end select;


With the TeleGen compiler, the program prints "we made it" then exits.
This does not seem correct to me.  When I compile this with the Verdix
Ada compiler on our Vax, the program prints "==> DEADLOCK! <== No tasks
to run, no delays waiting."  If I change the "or" marked with "XXX" to
an "else," the programs works "as expected" for both compilers, i.e.
it prints "can't accept yet" 9 times, then prints "we made it" and exits.

Anyone have any ideas?  Please email unless you feel it would be of
interest to the group as a whole.  Many thanks in advance!

P.S. If you want to try the program on your compiler, I'd be interested
to know what happens.


RESPONSE:

I ran this on DEC Ada ... worked "as expected" ( I seem to trust DEC's
Ada compiler more than most other products, sometimes even more than
the LRM).

It is interesting to note that Dave Stein reports different effects
when he replaces the "or" statement with an "else". This may be an 
indicator to the real problem. The interpretation of a delay 
statement in the original context implies that the accept alternative 
"maybe" could be accepted within one second. Using the "else" clause,
once it is determined the accept alternative is not ready for rendevous,
there must be a delay of at least one second. The execution Dave
describes is still faulty for both Telegen and Verdix, but the problem
appears to be in the implementation of the delay statement used as a
timeout facility, not a faulty guard statement.

Rich DeSimine
AT&T Bell Laboratories
(201) 386-2059