On Sunday, June 13, 2021 at 11:46:23 AM UTC-5, Dan Winslow wrote:
> On Sunday, June 13, 2021 at 11:44:00 AM UTC-5, Dan Winslow wrote:
> > On Sunday, June 13, 2021 at 8:16:31 AM UTC-5, Jeffrey R. Carter wrote:
> > > On 6/13/21 2:06 PM, Dan Winslow wrote:
> > > >
> > > > Well. You are confirming that I shouldn't expect the behavior I am looking for? How does linux do in this regard, I could use it if needed.
> > > with Xubuntu 21.04 and GNAT 11 I get
> > >
> > > ~/Code$ ./winslow
> > > 8 CPUs
> > > one
> > > Task one done, x= 1000001
> > > two
> > > Task two done, y= 1000001
> > > main done, x 1000001 y 1000001
> > >
> > > I get this with or without the scheduling pragma in gnat.adc.
> > >
> > > --
> > > Jeff Carter
> > > "Don't knock masturbation. It's sex with someone I love."
> > > Annie Hall
> > > 45
> > Yep, just found that myself. So, I guess since the tasks get mapped onto underlying os threads, windows has its own ideas and does things like automatic priority promotion and other non-compliant stuff. Too bad, but I guess kind of makes sense because windows does everything possible, most likely, to prevent any kind of thread monopolization. Would be nice if the gnat windows version at least threw a warning that 'hey, it's legal, but it aint gonna work on windows'.
> >
> > So, works perfectly on linux. Probably would on windows too if I knew how to swap out for a pthreads implementation on windows.
> >
> > Thanks!
> Odd that it doesn't require the gnat.adc pragma though. I suppose linux is counting on delay statements or other sync points to swap. For what I need, that's perfect.
Order of start on the two tasks is random on linux, too. It's usually task one but sometimes task 2 starts first.

Niklas Holsti schrieb am Samstag, 12. Juni 2021 um 20:02:58 UTC+2:
> I haven't found any connection between dispatching points and updates to
> globals in RM Annex D, where dispatching points are defined.
> > So taks One could infact consider Y constant within the loop.

Hm, you're right, I cannot find such a statement in the post-Ada83 RM.

Ada 83 ,9.11, has it. These points are called sychronization points.

I learned Ada in the 80s - old memories stick.

On 6/13/21 6:46 PM, Dan Winslow wrote:
>
> Odd that it doesn't require the gnat.adc pragma though. I suppose linux is counting on delay statements or other sync points to swap. For what I need, that's perfect.

I'm surprised the tasks don't swap when one does I/O.

--
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45

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

On Sun, 13 Jun 2021 09:43:59 -0700 (PDT), Dan Winslow
<dandwinslow@gmail.com> declaimed the following:

>Yep, just found that myself. So, I guess since the tasks get mapped onto underlying os threads, windows has its own ideas and does things like automatic priority promotion and other non-compliant stuff. Too bad, but I guess kind of makes sense because windows does everything possible, most likely, to prevent any kind of thread monopolization. Would be nice if the gnat windows version at least threw a warning that 'hey, it's legal, but it aint gonna work on windows'.
>
Priority promotion is a concept inherited from DEC (open)VMS, where
normal user processes had a base priority (which they never dropped below),
but would get priority boosts if it wasn't scheduled over some number of
quantums. And similarly, the top half or so of the priority range was
considered "realtime" and fixed (no priority boosting).

Setting your program to one of Windows "realtime" levels (16-31), might
have some effect on how the program behaves since I believe those too are
fixed priority.

Supposedly NTFS also inherited some VMS concepts -- but if so, M$
managed to obscure them from regular users.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On Sunday, June 13, 2021 at 12:44:10 PM UTC-5, Jeffrey R. Carter wrote:
> On 6/13/21 6:46 PM, Dan Winslow wrote:
> >
> > Odd that it doesn't require the gnat.adc pragma though. I suppose linux is counting on delay statements or other sync points to swap. For what I need, that's perfect.
> I'm surprised the tasks don't swap when one does I/O.
> --
> Jeff Carter
> "Don't knock masturbation. It's sex with someone I love."
> Annie Hall
> 45

I thought about that too. Blocked IO in this case is unlikely, but a thread put to sleep waiting on IO completion I can certainly see being swapped. Still, if Annex D is strictly respected it shouldn't...I'm starting to wonder what OS actually does fully implement Annex D.

On Mon, 14 Jun 2021 17:41:09 -0700 (PDT), Dan Winslow
<dandwinslow@gmail.com> declaimed the following:

>
>I thought about that too. Blocked IO in this case is unlikely, but a thread put to sleep waiting on IO completion I can certainly see being swapped. Still, if Annex D is strictly respected it shouldn't...I'm starting to wonder what OS actually does fully implement Annex D.

Probably custom BARE-BONES Ada RunTime libraries... Basically, no OS,
and the library has to implement all process switching internally.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/