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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:cc6:: with SMTP id 189mr13972991qkm.261.1623620625563; Sun, 13 Jun 2021 14:43:45 -0700 (PDT) X-Received: by 2002:a25:e658:: with SMTP id d85mr7897605ybh.165.1623620625282; Sun, 13 Jun 2021 14:43:45 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 13 Jun 2021 14:43:45 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c00:c1d:4b00:6504:2af1:1ca4:316f; posting-account=-iT6ZQoAAAAlqBCInAc-vB6x1soT8Jhq NNTP-Posting-Host: 2001:1c00:c1d:4b00:6504:2af1:1ca4:316f References: <1d798609-8b73-4bc6-b74f-e435e8af8fedn@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <98e0acbd-eba6-4c41-b677-7a2208201cf1n@googlegroups.com> Subject: Re: non-preemptive tasking on GNAT 2020 Windows 10 multicore AMD From: darek Injection-Date: Sun, 13 Jun 2021 21:43:45 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62223 List-Id: On Sunday, 13 June 2021 at 11:13:55 UTC+2, Dmitry A. Kazakov wrote: > 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 As far as I know, there is no need for the explicit yielding. The compiler inserts these actions automatically (section 2.3.1, and section 4 for more details). Guys at ETHZ do things in a bit different way :). Regards, Darek P.S. For curious minds, the (Active) Oberon language report can be found here: http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/LanguageReport/OberonLanguageReport.pdf