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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Timeouts in Ada Date: Thu, 17 Jul 2014 12:27:15 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <50bdb713-7ce1-411b-810b-9bdee1d26b7a@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 17 Jul 2014 19:27:17 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="ec00b5351686c67721798cbf9cd968b0"; logging-data="29772"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xqodPuMwFpnUCT89ZZH6ZlT9tiTZbeyc=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <50bdb713-7ce1-411b-810b-9bdee1d26b7a@googlegroups.com> Cancel-Lock: sha1:mPWB7+m7EE6pnFDULyYJdskLiCo= Xref: news.eternal-september.org comp.lang.ada:21015 Date: 2014-07-17T12:27:15-07:00 List-Id: 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