Re: non-preemptive tasking on GNAT 2020 Windows 10 multicore AMD

[darek <darek.maksimiuk@gmail.com>]

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" <christ-u...@t-online.de> 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