comp.lang.ada
 help / color / mirror / Atom feed
From: rds@moss.ATT.COM
Subject: Telegen Ada guard evaluation
Date: 26 May 88 17:57:27 GMT	[thread overview]
Message-ID: <27110@clyde.ATT.COM> (raw)

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

             reply	other threads:[~1988-05-26 17:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1988-05-26 17:57 rds [this message]
1988-06-10 14:27 ` Telegen Ada guard evaluation Burch Seymour
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox