From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: non-preemptive tasking on GNAT 2020 Windows 10 multicore AMD Date: Sun, 13 Jun 2021 11:13:53 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1d798609-8b73-4bc6-b74f-e435e8af8fedn@googlegroups.com> NNTP-Posting-Host: 5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62212 List-Id: On 2021-06-13 10:04, darek wrote: > On Sunday, 13 June 2021 at 08:20:08 UTC+2, Randy Brukardt wrote: >> "AdaMagica" wrote in message >> news:1d798609-8b73-4bc6...@googlegroups.com... >>> Dmitry A. Kazakov schrieb am Samstag, 12. Juni 2021 um 17:57:39 UTC+2: >>>> Because under Windows the default priority is in the time sharing class. >>>> As the name suggests such threads are preempted when the their quant >>>> expires. AFAIK, even a lower priority thread can preempt a higher >>>> priority one if both are time sharing. Time sharing priority only >>>> influences the duration of the quant and the chances to gain the >>>> processor. >>> >>> Hm OK. Is this compatible with the Ada RM? >> Not really, at least in an Annex D sense. (The core doesn't require much, in >> part so Ada will work on a wide variety of targets.) Pretty much everyone >> has agreed to ignore the impossibility of implementing Annex D on Windows -- >> remember that there is an "impossible or impractical" exception in 1.1.3 >> which certainly applies in this case. Indeed, I suspect that it is >> impossible to implement all of Annex D on any target other than a bare >> machine. (One example is that there is no known implementation of EDF >> scheduling even though Annex D seems to require it to be implemented.) >> >> Randy. > > > Hi All, > It could be useful for Ada community - a bit different (and refreshing) approach : > > https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/154828/eth-47094-02.pdf Maybe I am wrong, but it looks to me like these guys spent 30 years in a time capsule. What the paper describes is basically Ada 95 protected action. "uncooperative" = protected action. [They do refer Ada once, but not its protected objects] The rest is musing about co-routines which are another 60 years old, or so. Yes, I would welcome co-routines as a special form of Ada task, but of course without explicit yielding. Obligatory explicit yielding kills task abstraction. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de