non-preemptive tasking on GNAT 2020 Windows 10 multicore AMD

non-preemptive tasking on GNAT 2020 Windows 10 multicore AMD

[Dan Winslow]

I am trying to achieve true non-preemptive tasking using gnat 2020 CE on a windows 10 environment. I have placed this in the gnat.adc file:

pragma Task_Dispatching_Policy(Non_Preemptive_FIFO_Within_Priorities);

Without this gnat.adc setting, the tasks switched back and forth a great deal, as you would expect with preemptive tasking. Putting the pragma in the gnat.adc file seemed to affect the granularity of the task switching on my test program below, in that it lengthened the time that each task executed consecutive loops, but they still switched over to each other eventually. Here is the test program:


with Ada.Text_IO; Use Ada.Text_Io;
 
procedure Test is


   Task Type One is
   End;  

   Task Type Two;

   Task body One is
     x : Integer := 0;
   Begin
     put_line("one");
     Loop
       x:=x+1;
       if x > 10000000 Then
         exit;
       end if;  
     End Loop;
     Put_line("Task one done, x=" & x'img);
   End;

   Task body Two is
     x : Integer := 0;
   Begin
     put_line("two");
     Loop
       x:=x+1;
       if x > 1000 Then
         exit;
       end if;  
     End Loop;
     Put_line("Task two done, x=" & x'img);
   End;

  a : One;
  B : two;
begin
   
  Null;
End;

Here is the compile line:

gnatmake -gnat2012 -gnatX -f -g test.adb -gnatwA -I. -I..  -D obj


And here is the output:

one
two
Task two done, x= 1001
Task one done, x= 10000001


I expected the opposite, that task one would execute first, which it did, but that it would also finish first because there's no reason for it to yield to two without preemption. It looks to me like I am not actually getting non-preemptive tasking, and I would like to know why.

After some looking I found the 2012 attribute 'with CPU', and produced test code :

With System.Multiprocessors;     use System.Multiprocessors;

with Ada.Text_IO; Use Ada.Text_Io;
 
procedure Test is

   Task Type One with Cpu=>1 is
   End;  

   Task Type Two with Cpu=> 1 is
   end;
   
   x,y : integer := 0;
   limit : integer := 1000000;

   Task body One is
   Begin
     put_line("one");
     Loop
       if y > 0 then 
         raise tasking_error;
       end if;  
       x:=x+1;
       if x > limit Then
         exit;
       end if;  
     End Loop;
     Put_line("Task one done, x=" & x'img);
   Exception
     When others =>
     put_line("task one died, x=" & x'img);  
   End;

   Task body Two is
   Begin
     put_line("two");
     Loop
       y:=y+1;
       if y > limit Then
         exit;
       end if;  
     End Loop;
     Put_line("Task two done, y=" & y'img);
   Exception
     When others =>
     put_line("task two died");  
   End;

  a : One;
  B : two;
begin
  put_line(Number_Of_CPUs'img & " cpu's"); 
  While (x < limit+1) or (y < limit+1) loop
    Delay 0.0;
  End Loop;  
  put_line("main done, x " & x'img & " y " & y'img);
End;


which produces output


one
two
 24 cpu's
task one died, x= 310528
Task two done, y= 1000001
^C

(of course, I have to ctl-c out since main never finishes.)

This happens whether or not I have the scheduling pragma in gnat.adc. Does Windows just not respect processor assignment and/or the scheduling pragma?

(Sorry for no code blocks, not sure how to do that here)

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

[Dmitry A. Kazakov]

On 2021-06-12 14:51, Dan Winslow wrote:
> I am trying to achieve true non-preemptive tasking using gnat 2020 CE on a windows 10 environment. I have placed this in the gnat.adc file:

[...]

> This happens whether or not I have the scheduling pragma in gnat.adc. Does Windows just not respect processor assignment and/or the scheduling pragma?

AFAIK, your tasks, if mapped onto threads, must have HIGH_PRIORITY_CLASS 
in order to not be preempted.

 
https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities

Did you try to change task priorities? I would suggest that and also 
looking into the process' threads while it is running to see the effect 
of the pragmas on the Windows side.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[AdaMagica]

RM 9.2(3/2) does not state in which order the tasks begin to run. They are activated together, then they are put in the ready queue in some order (there is not statement about the order in thr RM in the absence of prios). So I do not see that One has to run first.
Secondly, there is no priority defined, so they both have the same prio. Since there are no dispatching points as far as I can see, I do not understand why the running task should be preempted.
I had expected the task that is the first in the ready queue runs until it is done (this is a dispatching point), then the other will get the processor.

I didn't takeinto account how the pragma changes the default scheduling scheme.

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

[Dmitry A. Kazakov]

On 2021-06-12 17:43, AdaMagica wrote:

> Secondly, there is no priority defined, so they both have the same prio. Since there are no dispatching points as far as I can see, I do not understand why the running task should be preempted.

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[AdaMagica]

There is another importatn point. X and Y are global, and a task may update globals only at dispatching points. So taks One could infact consider Y constant within the loop. You did not specify Volatile.

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

[AdaMagica]

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?

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

[Dmitry A. Kazakov]

On 2021-06-12 18:05, AdaMagica wrote:
> 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?

Unless tasks are scheduled by Ada from a single thread, it is difficult 
to implement without having administrative rights. I wonder if the 
behavior would change should the process start elevated and/or on a real 
time priority. Something like that could be a prerequisition for the 
pragma to work. One should take a look on the implementation notes...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dan Winslow]

Great stuff, all, thanks. I was not counting on the order of start of the tasks. I will look into priorities and see what that does. Did not think that global non-volatile access would force a task switch, but I will look into that as well. Will post back with findings.

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

[Dan Winslow]

On Saturday, June 12, 2021 at 12:18:58 PM UTC-5, Dan Winslow wrote:
> Great stuff, all, thanks. I was not counting on the order of start of the tasks. I will look into priorities and see what that does. Did not think that global non-volatile access would force a task switch, but I will look into that as well. Will post back with findings.

How does one edit a post here?

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

[Niklas Holsti]

On 2021-06-12 19:03, AdaMagica wrote:
> There is another importatn point. X and Y are global, and a task may
> update globals only at dispatching points.


Updates to globals can be delayed, yes. But where in the RM does it say 
that a task cannot delay updates to non-volatile globals past 
dispatching points?

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.

Yes.

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

[Dennis Lee Bieber]

On Sat, 12 Jun 2021 10:21:07 -0700 (PDT), Dan Winslow
<dandwinslow@gmail.com> declaimed the following:

>On Saturday, June 12, 2021 at 12:18:58 PM UTC-5, Dan Winslow wrote:
>> Great stuff, all, thanks. I was not counting on the order of start of the tasks. I will look into priorities and see what that does. Did not think that global non-volatile access would force a task switch, but I will look into that as well. Will post back with findings.
>
>How does one edit a post here?

	This is Usenet -- posts get distributed to multiple servers (which
somehow manage to keep threads in order; a reply can hit a server before
the original message does).

	So... Once you submit a post, it is out there and nothing can be done
to it. The NNTP protocol behind Usenet does define a CANCEL operation, but
most servers ignore them (there is no authorization that the person doing
the CANCEL was the originator of the post).


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

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

[Dan Winslow]

On Saturday, June 12, 2021 at 1:02:58 PM UTC-5, Niklas Holsti wrote:
> On 2021-06-12 19:03, AdaMagica wrote: 
> > There is another importatn point. X and Y are global, and a task may 
> > update globals only at dispatching points.
> Updates to globals can be delayed, yes. But where in the RM does it say 
> that a task cannot delay updates to non-volatile globals past 
> dispatching points? 
> 
> 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.
> Yes.

Yes, that was my thought too, but I'm no expert. These tasks have no dispatches at all, that's the point. I expected whichever one started first to run to completion, then the other while main was pending exit (or looping, as I set up later). They were both on the same CPU, non-preemptive was set, yet they clearly task switched.

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

[Dan Winslow]

On Saturday, June 12, 2021 at 11:30:37 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2021-06-12 18:05, AdaMagica wrote: 
> > 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?
> Unless tasks are scheduled by Ada from a single thread, it is difficult 
> to implement without having administrative rights. I wonder if the 
> behavior would change should the process start elevated and/or on a real 
> time priority. Something like that could be a prerequisition for the 
> pragma to work. One should take a look on the implementation notes...
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de


run as admin made no difference.

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

[Dan Winslow]

So, I am puzzled. Nothing I do makes any different whatsoever in how the little test program runs. Setting the scheduling police, setting the task individual priorities to Max_Priority, running as admin, setting pragma Locking_Policy(Ceiling_Locking), etc. Nothing stops it from this exact output (except a slight variance in the X number)

one
two
 24 cpu's
task one died, x= 397682
Task two done, y= 1000001
^C

Kind of disheartening, and I'm not sure where to go next. I don't so much require a non-preemptive scheduler, but my inability to affect any behavior at all for teh tasking is really wierd, and seems like a bug of the underlying system. Anyone have any ideas? Is there some fundamental flaw in my little test program I'm missing?
















,

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

[Dennis Lee Bieber]

On Sat, 12 Jun 2021 15:21:35 -0700 (PDT), Dan Winslow
<dandwinslow@gmail.com> declaimed the following:


>Kind of disheartening, and I'm not sure where to go next. I don't so much require a non-preemptive scheduler, but my inability to affect any behavior at all for teh tasking is really wierd, and seems like a bug of the underlying system. Anyone have any ideas? Is there some fundamental flaw in my little test program I'm missing?

	I suspect part of the problem may be that the GNAT runtime defers to
the OS for how tasks (threads/processes) are implemented (AdaCore probably
gets a fortune for configuring a bare-bones runtime that supports tasking).
Since Windows will have a lot of time-slicing and interrupts, ANY
task/thread is subject to preemption -- and on preemption, it likely goes
to the end of any round-robin within priorities queue.

https://www.microsoftpressstore.com/articles/article.aspx?p=2233328&seqNum=7

{Interesting -- about half-way down that page it states that a preempted
thread is put on the /head/ of the queue for its priority level, so that it
can later be restarted to "finish" its time quantum}


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

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

[Dennis Lee Bieber]

On Sat, 12 Jun 2021 21:24:58 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> declaimed the following:

>	I suspect part of the problem may be that the GNAT runtime defers to
>the OS for how tasks (threads/processes) are implemented (AdaCore probably

	Also see
https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/platform_specific_information.html

"""
Choosing the Scheduling Policy

When using a POSIX threads implementation, you have a choice of several
scheduling policies: SCHED_FIFO, SCHED_RR and SCHED_OTHER.
"""
	Unfortunately -- POSIX threads means, I believe, pthreads library...
That is not native on Windows, just Linux and Mac... Don't know if

"""
wPOSIX

wPOSIX is a minimal POSIX binding whose goal is to help with building
cross-platforms applications. This binding is not complete though, as the
Win32 API does not provide the necessary support for all POSIX APIs.

To use the wPOSIX binding you need to use a project file, and adding a
single with_clause will give you full access to the wPOSIX binding sources
and ensure that the proper libraries are passed to the linker.

    with "wposix";
    project P is
       for Sources use ...;
    end P;

To build the application you just need to call gprbuild for the
application’s project, here p.gpr:

    gprbuild p.gpr
"""

is sufficient to get POSIX threading... I don't see anything in
https://github.com/AdaCore/wposix/tree/master/src that seems specific to
threading



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

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

[Randy Brukardt]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:1d798609-8b73-4bc6-b74f-e435e8af8fedn@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.

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

[darek]

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

 Darek

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

[Dmitry A. Kazakov]

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

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

[J-P. Rosen]

Le 13/06/2021 à 00:21, Dan Winslow a écrit :
> So, I am puzzled. Nothing I do makes any different whatsoever in how the little test program runs.

Hmmm... Scheduling matters only if you have less CPUs than tasks. If you 
have two tasks and more than two CPUs, the tasks will effectively run 
concurrently, and priorities have no effect.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

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

[Dan Winslow]

> 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.

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.

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

[Dan Winslow]

On Sunday, June 13, 2021 at 5:24:29 AM UTC-5, J-P. Rosen wrote:
> Le 13/06/2021 à 00:21, Dan Winslow a écrit : 
> > So, I am puzzled. Nothing I do makes any different whatsoever in how the little test program runs.
> Hmmm... Scheduling matters only if you have less CPUs than tasks. If you 
> have two tasks and more than two CPUs, the tasks will effectively run 
> concurrently, and priorities have no effect. 
> 
> -- 
> J-P. Rosen 
> Adalog 
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX 
> Tel: +33 1 45 29 21 52 
> https://www.adalog.fr

I know how multiprocessing works. I am using an Annex D facility that is supposed to set non-preemptive, and both tasks are on the same core (assuming THAT works on windows). One task should monopolize, then the next, and then main terminate.

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

[Jeffrey R. Carter]

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

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

[Dan Winslow]

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!

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

[Dan Winslow]

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.

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

[Dan Winslow]

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.

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

[AdaMagica]

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.

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

[Jeffrey R. Carter]

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

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

[darek]

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

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

[Dennis Lee Bieber]

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/

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

[Dan Winslow]

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.

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

[Dennis Lee Bieber]

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/