Re: Timeouts in Ada

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 07/16/2014 10:18 PM, NiGHTS wrote:
>
> Now as an Ada beginner with a strong background in C/Asm I interpret this
> example in the following way...
>
> 1. "select" creates a thread which runs the body of "select" or the body of
> "or". Or maybe it creates two threads for each and blocks its own thread
> until one finishes.

You've had lots of good answers to this. I'm going to try to look at it a bit 
differently to see if that helps.

Ada's tasking features are high-level and biased towards safety. Things like 
mutexes are sort of like the machine code that Ada's tasking structures are 
implemented with, just as an if statement is implemented with conditional gotos. 
You shouldn't think in terms of conditional gotos, and you shouldn't think in 
terms of low-level concurrency primitives. In this case, your experience using 
low-level languages works against you.

Ada defines the effect of using its tasking features, not how that effect is 
obtained. You are asking about the latter. That is like asking how code is 
generated for an if statement. Unless you're a compiler writer, it's really not 
important, so long as you understand the effect of the if statement. And just as 
on this processor an if may be implemented using a BNE instruction, and on 
another with a JNZ, how Ada's tasking is implemented will vary based on the target.

Generally, between your code and the platform there will be an Ada run-time 
library (RTL). Your code will be translated into calls to the RTL.

If you're targeting bare metal, there will be nothing below the RTL. All tasking 
and scheduling will be done by the RTL.

If you're targeting an OS, generally the RTL will use OS services to implement 
tasking. Tasks will be mapped onto OS threads, delays onto timers, and so forth.

While an implementation might decide to create a thread or 2 as you suggest, 
it's unlikely. There's a task T that executes the select statement. Most likely 
T has the scheduler create a timer and queue the entry call, then blocks. 
Eventually something happens that causes the scheduler to make T runnable again, 
and some time after that the scheduler will run T again. Then T will look at the 
event that allowed it to run again and take one of the 2 branches based on that.

The important thing is that T waits for one of those 2 events (entry call going 
through or delay expiring) and then completes the corresponding branch of the 
select. How that is implemented is no more important than what machine code is 
generated for an if.

Finally, most of the answers talk about the delay being canceled when the entry 
call is accepted. Reality is more murky than that. The entry call can be 
accepted, then requeued "with abort", and the delay can still cancel the entry 
call, and the accept-requeue sequence can happen any number of times. Generally 
entry calls are "abort deferred", so if the call is accepted and is not 
currently requeued with abort, the call cannot be canceled. So a more complete 
answer may be, if the entry call has not been accepted, or has been accepted but 
is currently requeued with abort, then the time out will cancel the entry call. 
Otherwise the entry call will complete. I'm not clear about what happens if the 
entry call completes but the time out expires before it does, but I think in 
that case the select branch is completed and the or branch is ignored.

(Originally the semantics were defined in terms of the entry call being accepted 
because Ada 83 didn't have requeue. Ada 95 introduced requeue and things got murky.)

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107