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)

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

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.

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

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.

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?

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

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.

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?

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.

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/

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.

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.

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?

,

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/

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/

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

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

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

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

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

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.

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

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!

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.