tasking with GNAT 3.14p on windows

tasking with GNAT 3.14p on windows

[Bernd Specht]

Hi,

I tried an example from "Barnes, 18.8", but it didn't work as expected. Any 
ideas?

with Text_IO; use Text_IO;

procedure TaskTest is
begin
  select
    delay 3.0;
    put_line ("aborted");
  then abort
    loop 
      null; -- modified
    end loop;
  end select;
end TaskTest;
 

The computation is not aborted (what I would expect). Do I misunderstand 
something?

Re: tasking with GNAT 3.14p on windows

[James S. Rogers]

"Bernd Specht" <Bernd.Specht@gmx.com> wrote in message
news:Xns934E8C5D49EFBerndSpechtgmxcom@62.153.159.134...
> Hi,
>
> I tried an example from "Barnes, 18.8", but it didn't work as expected.
Any
> ideas?
>
> with Text_IO; use Text_IO;
>
> procedure TaskTest is
> begin
>   select
>     delay 3.0;
>     put_line ("aborted");
>   then abort
>     loop
>       null; -- modified
>     end loop;
>   end select;
> end TaskTest;
>
>
> The computation is not aborted (what I would expect). Do I misunderstand
> something?

Yes, you are misunderstanding something.

This mechanism is sometimes called asynchronous transfer of control.
The abortable part of your construct above is the null command.
The null command will reliably take less than 3.0 seconds to complete.
Whatever was in the original example in place of the null statement was
the abortable part. The idea is that your program will start the abortable
part and wait until the delay statement completes. If the abortable part
completes first then the delay statement, and the statements following
it before "then abort" are cancelled. If the delay statement finishes
before the aboratble part, then the abortable part is aborted and
the message following the delay statement is executed.

All this said, the GNAT on windows operating systems does not
properly support asynchronous transfer of control.

Jim Rogers

Re: tasking with GNAT 3.14p on windows

[Jano]

James S. Rogers dice...
> "Bernd Specht" <Bernd.Specht@gmx.com> wrote in message
> news:Xns934E8C5D49EFBerndSpechtgmxcom@62.153.159.134...
> > Hi,
> >
> > I tried an example from "Barnes, 18.8", but it didn't work as expected.
> Any
> > ideas?
> >
> > with Text_IO; use Text_IO;
> >
> > procedure TaskTest is
> > begin
> >   select
> >     delay 3.0;
> >     put_line ("aborted");
> >   then abort
> >     loop
> >       null; -- modified
> >     end loop;
> >   end select;
> > end TaskTest;
> >
(...)
> The null command will reliably take less than 3.0 seconds to complete.

It's inside of a neverending loop.

> All this said, the GNAT on windows operating systems does not
> properly support asynchronous transfer of control.

It's somewhere documented the Gnat limitations on windows and their 
consequences? The ATC is hinted to not work correctly even with polling 
enabled, but some others are absent I think from documentation. 

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[James S. Rogers]

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.18f18ac32e4a300d9896c8@News.CIS.DFN.DE...
> James S. Rogers dice...
> > "Bernd Specht" <Bernd.Specht@gmx.com> wrote in message
> > news:Xns934E8C5D49EFBerndSpechtgmxcom@62.153.159.134...
> > > Hi,
> > >
> > > I tried an example from "Barnes, 18.8", but it didn't work as
expected.
> > Any
> > > ideas?
> > >
> > > with Text_IO; use Text_IO;
> > >
> > > procedure TaskTest is
> > > begin
> > >   select
> > >     delay 3.0;
> > >     put_line ("aborted");
> > >   then abort
> > >     loop
> > >       null; -- modified
> > >     end loop;
> > >   end select;
> > > end TaskTest;
> > >
> (...)
> > The null command will reliably take less than 3.0 seconds to complete.
>
> It's inside of a neverending loop.

And optimization will remove the loop, leaving a single null statement.

Jim Rogers

Re: tasking with GNAT 3.14p on windows

[James S. Rogers]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:W4Oha.35749$ja4.2291095@bgtnsc05-news.ops.worldnet.att.net...
> "Jano" <nono@celes.unizar.es> wrote in message
> news:MPG.18f18ac32e4a300d9896c8@News.CIS.DFN.DE...
> > James S. Rogers dice...
> > > "Bernd Specht" <Bernd.Specht@gmx.com> wrote in message
> > > news:Xns934E8C5D49EFBerndSpechtgmxcom@62.153.159.134...
> > > > Hi,
> > > >
> > > > I tried an example from "Barnes, 18.8", but it didn't work as
> expected.
> > > Any
> > > > ideas?
> > > >
> > > > with Text_IO; use Text_IO;
> > > >
> > > > procedure TaskTest is
> > > > begin
> > > >   select
> > > >     delay 3.0;
> > > >     put_line ("aborted");
> > > >   then abort
> > > >     loop
> > > >       null; -- modified
> > > >     end loop;
> > > >   end select;
> > > > end TaskTest;
> > > >
> > (...)
> > > The null command will reliably take less than 3.0 seconds to complete.
> >
> > It's inside of a neverending loop.
>
> And optimization will remove the loop, leaving a single null statement.

I tried asynchronous transfer of control using the free Aonix compiler.
It worked on my Windows 98 laptop.

Jim Rogers

Re: tasking with GNAT 3.14p on windows

[Sergey Koshcheyev]

James S. Rogers wrote:
>>>The null command will reliably take less than 3.0 seconds to complete.
>>
>>It's inside of a neverending loop.
> 
> 
> And optimization will remove the loop, leaving a single null statement.

Such an optimization will also be implemented in hardware in the 
upcoming Pentium V processors, which are rumored to be able to execute 
an infinite loop in just about two minutes :-)

Sergey.

> 
> Jim Rogers

Re: tasking with GNAT 3.14p on windows

[@ 2003-03-31 9:00 UTC (permalink / raw)]

Sergey Koshcheyev wrote:
> James S. Rogers wrote:
> 
>>>> The null command will reliably take less than 3.0 seconds to complete.
>>>
>>>
>>> It's inside of a neverending loop.
>>
>>
>>
>> And optimization will remove the loop, leaving a single null statement.
> 
> 
> Such an optimization will also be implemented in hardware in the 
> upcoming Pentium V processors, which are rumored to be able to execute 
> an infinite loop in just about two minutes :-)
> 
> Sergey.
> 
>>
>> Jim Rogers


   Compiling with "gnatmake -O3" the loop is (fortunately) still there 
(again, Red Hat 7.3, GNAT 3.15p). No optimization should change the 
semantics of a loop.

Rodrigo

Re: tasking with GNAT 3.14p on windows

[Bernd Specht]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote in 
news:W4Oha.35749$ja4.2291095@bgtnsc05-news.ops.worldnet.att.net:

> "Jano" <nono@celes.unizar.es> wrote in message
> news:MPG.18f18ac32e4a300d9896c8@News.CIS.DFN.DE...
>> James S. Rogers dice...
>> > "Bernd Specht" <Bernd.Specht@gmx.com> wrote in message
>> > news:Xns934E8C5D49EFBerndSpechtgmxcom@62.153.159.134...
>> > > Hi,
>> > >
>> > > I tried an example from "Barnes, 18.8", but it didn't work as
>> > > expected. Any ideas? 
>> > >
>> > > with Text_IO; use Text_IO;
>> > >
>> > > procedure TaskTest is begin
>> > >   select
>> > >     delay 3.0;
>> > >     put_line ("aborted");
>> > >   then abort
>> > >     loop
>> > >       null; -- modified
>> > >     end loop;
>> > >   end select;
>> > > end TaskTest;
>> > >
>> (...)
>> > The null command will reliably take less than 3.0 seconds to complete.
>>
>> It's inside of a neverending loop.
> 
> And optimization will remove the loop, leaving a single null statement.

No.

1. If this would be true, then the program should terminate after a short 
time, but in fact it is still not terminated after a few hours. so it seem 
to "hang" inside the loop.


2. If this would be the  case it would be a serious compiler error. An 
endless loop must never be removed by compiler optimisation (it would be 
interessting to know the opinion of Robert Dewar).

I hope my code

loop
  if Get_Pressure > Upper_Limit
  then
    Open_Valve;
  elsif Get_Pressure < Lower_Limit
  then
    Close_Valve;
  end if;
end loop;


still executes, and was not only executed once due to compiler optimisation 
(I don't like to be blown up due to an compiler "feature").

> 
> Jim Rogers
> 
> 
> 

Re: tasking with GNAT 3.14p on windows

[Chad R. Meiners]

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.18f18ac32e4a300d9896c8@News.CIS.DFN.DE...
>
> It's somewhere documented the Gnat limitations on windows and their
> consequences? The ATC is hinted to not work correctly even with polling
> enabled, but some others are absent I think from documentation.

This is untrue!  With gnat on windows you simply have to enable polling to
get ATC's to work correctly.  I remember ATC working properly on windows
(with polling) since at least gnat 3.12p.  Incidently, on gnat 3.15p with
the command :
gnatmake -gnatP testtask.adb

you get an executable with the intended behavior.  I am sure that pragma
Polling would also work too.  So I would like to know where in the
documentation it is stated that ATC does not work due to Windows native
threading scheme or why you didn't even bother to compile and test program
with polling on.  It took a whole 30 seconds to do.

Re: tasking with GNAT 3.14p on windows

[Jano]

Chad R. Meiners dice...
> 
> "Jano" <nono@celes.unizar.es> wrote in message
> news:MPG.18f18ac32e4a300d9896c8@News.CIS.DFN.DE...
> >
> > It's somewhere documented the Gnat limitations on windows and their
> > consequences? The ATC is hinted to not work correctly even with polling
> > enabled, but some others are absent I think from documentation.
> 
> This is untrue!  With gnat on windows you simply have to enable polling to
> get ATC's to work correctly.  I remember ATC working properly on windows
> (with polling) since at least gnat 3.12p.  Incidently, on gnat 3.15p with
> the command :
> gnatmake -gnatP testtask.adb

Calm down ;-) I've done these tests myself. I was wondering about code 
laking the characteristics which trigger polling. I know, that's pretty 
rare and maybe not doable, but is a question that comes to my mind.

> you get an executable with the intended behavior.  I am sure that pragma
> Polling would also work too.  So I would like to know where in the
> documentation it is stated that ATC does not work due to Windows native
> threading scheme or why you didn't even bother to compile and test program
> with polling on.  It took a whole 30 seconds to do.

It's not stated. It's stated that without -gnatP, it doesn't work, and 
with it it inserts calls to the polling function under several cases 
(enough cases, I could agree).

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[@ 2003-03-31 7:57 UTC (permalink / raw)]

Bernd Specht wrote:
> Hi,
> 
> I tried an example from "Barnes, 18.8", but it didn't work as expected. Any 
> ideas?
> 
> with Text_IO; use Text_IO;
> 
> procedure TaskTest is
> begin
>   select
>     delay 3.0;
>     put_line ("aborted");
>   then abort
>     loop 
>       null; -- modified
>     end loop;
>   end select;
> end TaskTest;
>  
> 
> The computation is not aborted (what I would expect). Do I misunderstand 
> something?


   This example works as expected on my Red Hat 7.3 with GNAT 3.15p. I 
will try to run it on Windows 2000 to see if that is the problem.

   That would be strange anyway, since GNAT relies on pthreads for 
implementing its run-time. Is there a problem with pthreads 
implementation on Windows?

Rodrigo

Re: tasking with GNAT 3.14p on windows

[Ole-Hjalmar Kristensen]

Rodrigo Garc�a <rodrigo.garcia.ARROBA.epfl.ch> writes:

> Bernd Specht wrote:
> > Hi,
> > I tried an example from "Barnes, 18.8", but it didn't work as
> > expected. Any ideas?
> > with Text_IO; use Text_IO;
> > procedure TaskTest is
> > begin
> >   select
> >     delay 3.0;
> >     put_line ("aborted");
> >   then abort
> >     loop       null; -- modified
> >     end loop;
> >   end select;
> > end TaskTest;
> >  The computation is not aborted (what I would expect). Do I
> > misunderstand something?
> 
> 
>    This example works as expected on my Red Hat 7.3 with GNAT 3.15p. I
> will try to run it on Windows 2000 to see if that is the problem.
> 
>    That would be strange anyway, since GNAT relies on pthreads for
> implementing its run-time. Is there a problem with pthreads
> implementation on Windows?
> 
> Rodrigo
> 
Unless Microsoft has significantly improved the Pthreads support, it's
not a good idea to implement the GNAT runtime on top of Pthreads on
Windows.  From a quick look at the GNAT runtime, it seems like the
native NT interface is used, not Pthreads.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: tasking with GNAT 3.14p on windows

[Jano]

Ole-Hjalmar Kristensen dice...

> Unless Microsoft has significantly improved the Pthreads support, it's
> not a good idea to implement the GNAT runtime on top of Pthreads on
> Windows.  From a quick look at the GNAT runtime, it seems like the
> native NT interface is used, not Pthreads.

Docs says that Ada tasks are mapped to native threads, I don't know if 
that leaves room for pthreads (which I ignore).

I tried recently something like that:

select
   delay 10.0;
   put_line("aborted);
then abort
   get_line(text, last);
end select;

trying to know the behavior with blocking I/O. In XP with -gnatP, you 
get indefinite wait for user input, but if more than 10 seconds has 
passed when you hit enter, you get also the "aborted" print.

Is that expected behavior? Gnat docs say that polling implements calls 
in each loop iteration / function call. Should I assume that if you 
haven't loops / calls, abort will never work properly?

I feel nevertheless very unsafe using anything else than trivial tasks 
in NT. The priority system of NT messes things greatly out of 
real_time_class, and that, for example, is never pointed in Gnat docs 
(in my knowledge).

Also, the faulty ceiling_priority model for protected objects is 
mentioned or not? I can't remember...

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[Chad R. Meiners]

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE...
> trying to know the behavior with blocking I/O. In XP with -gnatP, you
> get indefinite wait for user input, but if more than 10 seconds has
> passed when you hit enter, you get also the "aborted" print.
>
> Is that expected behavior? Gnat docs say that polling implements calls
> in each loop iteration / function call. Should I assume that if you
> haven't loops / calls, abort will never work properly?

It seems like reasonable behavior.  System calls are not guaranteed to be
abortable.

> I feel nevertheless very unsafe using anything else than trivial tasks
> in NT. The priority system of NT messes things greatly out of
> real_time_class, and that, for example, is never pointed in Gnat docs
> (in my knowledge).

NT is not a real time operating system.  The task support on NT is not
broken; your understanding of Ada tasking is broken. ;)  It is very easy to
write system dependent tasking code.  I have written several robust
multi-tasking windows applications.  You just have to understand how to
implement your os calls so that they play well with tasking.

> Also, the faulty ceiling_priority model for protected objects is
> mentioned or not? I can't remember...

If you don't know then why are spreading FUD about tasking on NT?

Re: tasking with GNAT 3.14p on windows

[Jano]

Chad R. Meiners dice...
> 
> "Jano" <nono@celes.unizar.es> wrote in message
> news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE...
> > trying to know the behavior with blocking I/O. In XP with -gnatP, you
> > get indefinite wait for user input, but if more than 10 seconds has
> > passed when you hit enter, you get also the "aborted" print.
> >
> > Is that expected behavior? Gnat docs say that polling implements calls
> > in each loop iteration / function call. Should I assume that if you
> > haven't loops / calls, abort will never work properly?
> 
> It seems like reasonable behavior.  System calls are not guaranteed to be
> abortable.

That's what I wanted to know. I'm not a RM lawyer, so I don't knew that. 
I'll be glad if someone can point the relevant sections in the RM about 
code not abortable.

> > I feel nevertheless very unsafe using anything else than trivial tasks
> > in NT. The priority system of NT messes things greatly out of
> > real_time_class, and that, for example, is never pointed in Gnat docs
> > (in my knowledge).
> 
> NT is not a real time operating system. 

I know that.

> The task support on NT is not
> broken; your understanding of Ada tasking is broken. ;)  

;) As I've said, I'm not an Ada RM expert, but I think I'm not totally 
clueless about how a multitasking program should work, if the compiler 
adheres to annex D, as Gnat says. OTOH, as far as I know, Gnat isn't 
validated under win32.

> It is very easy to
> write system dependent tasking code.  I have written several robust
> multi-tasking windows applications.  You just have to understand how to
> implement your os calls so that they play well with tasking.

I've also written multitasking window apps, and I don't like the tricks 
you must do to workaround some NT limitations, and that's about I was 
asking. One of the points of using Ada is to remain as much as possible 
in the system independent side of the world ;-)

> > Also, the faulty ceiling_priority model for protected objects is
> > mentioned or not? I can't remember...
> 
> If you don't know then why are spreading FUD about tasking on NT?

Well, I was thinking out loud to see if someone shares my concerns. I 
like to be enlightened by others greater experience. I have nothing 
against Gnat nor intend to spread FUD.

The following points I believe are true, and not mentioned in Gnat NT 
documentation. I will not point the RM sections which I think aren't 
satisfied, but every time I try to read the D annex in detail, I feel a 
bit disturbed about Gnat saying it complies with it, hence my asking:

* You must set your app in realtime priority class because NT priorities 
below that class aren't static.

* You may have two tasks with different priorities specified via pragma 
priority. The two will map to the same NT priority (because there are 
less than in system.priority'range), and your tasks will preempt each 
other even having specified a higher priority for one of them. 

* The ceiling priority of protected objects is simply ignored. The 
caller will not inherit the ceiling priority. I was taught that in 
university, and my tests seem to confirm that. To be fair, I have a 
vague remembrance of reading about it, but can remember if it was in 
some papers from my professor or in Gnat docs.

These are valid concerns, I think, and not FUD. The former two I'm 
nearly sure are not in NT docs, and I think are very important for a 
newcomer which wants to experiment with tasking and has windows. You can 
blame me for trying to do realtime tasking in NT, but that's not my 
point. These things I've discovered not in gnat docs, and that was my 
original comment.

Please feel free to correct me.

Kind regards,

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[Chad R. Meiners]

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.18f2dca67f9d5139896cd@News.CIS.DFN.DE...
> Chad R. Meiners dice...
> >
> > "Jano" <nono@celes.unizar.es> wrote in message
> > news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE...
> > > trying to know the behavior with blocking I/O. In XP with -gnatP, you
> > > get indefinite wait for user input, but if more than 10 seconds has
> > > passed when you hit enter, you get also the "aborted" print.
> > >
> > > Is that expected behavior? Gnat docs say that polling implements calls
> > > in each loop iteration / function call. Should I assume that if you
> > > haven't loops / calls, abort will never work properly?
> >
> > It seems like reasonable behavior.  System calls are not guaranteed to
be
> > abortable.
>
> That's what I wanted to know. I'm not a RM lawyer, so I don't knew that.
> I'll be glad if someone can point the relevant sections in the RM about
> code not abortable.
>
> > > I feel nevertheless very unsafe using anything else than trivial tasks
> > > in NT. The priority system of NT messes things greatly out of
> > > real_time_class, and that, for example, is never pointed in Gnat docs
> > > (in my knowledge).
> >
> > NT is not a real time operating system.
>
> I know that.
>
> > The task support on NT is not
> > broken; your understanding of Ada tasking is broken. ;)
>
> ;) As I've said, I'm not an Ada RM expert, but I think I'm not totally
> clueless about how a multitasking program should work, if the compiler
> adheres to annex D, as Gnat says. OTOH, as far as I know, Gnat isn't
> validated under win32.
>
> > It is very easy to
> > write system dependent tasking code.  I have written several robust
> > multi-tasking windows applications.  You just have to understand how to
> > implement your os calls so that they play well with tasking.
>
> I've also written multitasking window apps, and I don't like the tricks
> you must do to workaround some NT limitations, and that's about I was
> asking. One of the points of using Ada is to remain as much as possible
> in the system independent side of the world ;-)
>
> > > Also, the faulty ceiling_priority model for protected objects is
> > > mentioned or not? I can't remember...
> >
> > If you don't know then why are spreading FUD about tasking on NT?
>
> Well, I was thinking out loud to see if someone shares my concerns. I
> like to be enlightened by others greater experience. I have nothing
> against Gnat nor intend to spread FUD.
>
> The following points I believe are true, and not mentioned in Gnat NT
> documentation. I will not point the RM sections which I think aren't
> satisfied, but every time I try to read the D annex in detail, I feel a
> bit disturbed about Gnat saying it complies with it, hence my asking:
>
> * You must set your app in realtime priority class because NT priorities
> below that class aren't static.
>
> * You may have two tasks with different priorities specified via pragma
> priority. The two will map to the same NT priority (because there are
> less than in system.priority'range), and your tasks will preempt each
> other even having specified a higher priority for one of them.
>
> * The ceiling priority of protected objects is simply ignored. The
> caller will not inherit the ceiling priority. I was taught that in
> university, and my tests seem to confirm that. To be fair, I have a
> vague remembrance of reading about it, but can remember if it was in
> some papers from my professor or in Gnat docs.
>
> These are valid concerns, I think, and not FUD. The former two I'm
> nearly sure are not in NT docs, and I think are very important for a
> newcomer which wants to experiment with tasking and has windows. You can
> blame me for trying to do realtime tasking in NT, but that's not my
> point. These things I've discovered not in gnat docs, and that was my
> original comment.
>
> Please feel free to correct me.
>
> Kind regards,
>
> --
> -------------------------
> Jano
> 402450.at.cepsz.unizar.es
> -------------------------

Re: tasking with GNAT 3.14p on windows

[Chad R. Meiners]

oops darn send button.

"Jano" <nono@celes.unizar.es> wrote in message
news:MPG.18f2dca67f9d5139896cd@News.CIS.DFN.DE...

> That's what I wanted to know. I'm not a RM lawyer, so I don't knew that.
> I'll be glad if someone can point the relevant sections in the RM about
> code not abortable.

I believe 9.8 Abort of a Task - Abort of a Sequence of Statements is
relevant but a I recomend reading
"Concurrency in Ada 95" by Burns (I think that is the author's name I can't
remember).

> > The task support on NT is not
> > broken; your understanding of Ada tasking is broken. ;)
>
> ;) As I've said, I'm not an Ada RM expert, but I think I'm not totally
> clueless about how a multitasking program should work, if the compiler
> adheres to annex D, as Gnat says. OTOH, as far as I know, Gnat isn't
> validated under win32.

You would have to contact ACT to get a validated compiler for any platform.

Actually section 9 on tasking is not that bad.  I do not claim to be an RM
expert either ;)  I do however make stabs at the document when I need to
answer a specific question though.

> > It is very easy to
> > write system dependent tasking code.  I have written several robust
> > multi-tasking windows applications.  You just have to understand how to
> > implement your os calls so that they play well with tasking.
>
> I've also written multitasking window apps, and I don't like the tricks
> you must do to workaround some NT limitations, and that's about I was
> asking. One of the points of using Ada is to remain as much as possible
> in the system independent side of the world ;-)

hmm.  I think I miscommunicated my point.  First, writing operating system
independent multi-tasking program is not obvious since tasking is often
misunderstood.  For example an common error is placing potentially blocking
system calls (such as file IO) within a protected action.  On most compilers
however wrapping your put_lines in a protected object does not cause any
problems, but some compilers might be able to detect that a blocking call is
being made at runtime and raise a Program_Error exception.  Care needs to
taken to implement a multi-tasking program in a way that its OS calls are
properly syncronized with the tasking system reguardless of the OS or
compiler

btw, what workarounds are you refering to?

> > > Also, the faulty ceiling_priority model for protected objects is
> > > mentioned or not? I can't remember...
> >
> > If you don't know then why are spreading FUD about tasking on NT?
>
> Well, I was thinking out loud to see if someone shares my concerns. I
> like to be enlightened by others greater experience. I have nothing
> against Gnat nor intend to spread FUD.

That's okay.  I misunderstood the context that you meant for your statements
;)  I've never looked at Annex D so I can't answer your questions on it.

-CRM

Re: tasking with GNAT 3.14p on windows

[Jano]

Chad R. Meiners dice...
> oops darn send button.

:)

> hmm.  I think I miscommunicated my point.  First, writing operating system
> independent multi-tasking program is not obvious since tasking is often
> misunderstood.  For example an common error is placing potentially blocking
> system calls (such as file IO) within a protected action.  On most compilers
> however wrapping your put_lines in a protected object does not cause any
> problems, but some compilers might be able to detect that a blocking call is
> being made at runtime and raise a Program_Error exception.  Care needs to
> taken to implement a multi-tasking program in a way that its OS calls are
> properly syncronized with the tasking system reguardless of the OS or
> compiler

Yes, one can always made mistakes. I'm more concerned about programs 
which doesn't use OS things nor do blocking calls inside protected 
objects. Programs which should be (fairly?) portable.

> btw, what workarounds are you refering to?

I was referring to the two first points in my other post: the need to 
raise your base priority to realtime class (with the danger it is if 
your program is buggy), and to know what are the mapping between the 31 
priorities in system.priority and the 7 in NT, which I have not handy, 
BTW, but could look if you are interested.

All this begins because at my college they use Ada to teach the real 
time programming subject. In the past we used ms-dos, meridian Ada (I 
think), and some hardware ad-hoc to simulate a vehicle and a dam. Later, 
when everything was being upgraded to windows, they found these things. 
I don't know what they are doing currently, but I suspect they never 
used windows in the end for the subject.

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[Robert A Duff]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Jano" <nono@celes.unizar.es> wrote in message
> news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE...
> > trying to know the behavior with blocking I/O. In XP with -gnatP, you
> > get indefinite wait for user input, but if more than 10 seconds has
> > passed when you hit enter, you get also the "aborted" print.
> >
> > Is that expected behavior? Gnat docs say that polling implements calls
> > in each loop iteration / function call. Should I assume that if you
> > haven't loops / calls, abort will never work properly?
> 
> It seems like reasonable behavior.  System calls are not guaranteed to be
> abortable.

The Ada RM has nothing to say about system calls, so of course they are
not guaranteed (by the RM) to be abortable.  But I'm very interested in
what GNAT does with system calls in the presence of abort.  Can you tell
us what happens if, say, a socket read is aborted?  And if it's not
abortable, how does one work around that fact?

Or suppose one task does a socket read, and another task gets aborted.
How well does that work?  On windows, I mean.  Assume polling is turned
on.

- Bob

Re: tasking with GNAT 3.14p on windows

[Chad R. Meiners]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcck7ef9bzv.fsf@shell01.TheWorld.com...
>
> The Ada RM has nothing to say about system calls, so of course they are
> not guaranteed (by the RM) to be abortable.  But I'm very interested in
> what GNAT does with system calls in the presence of abort.  Can you tell
> us what happens if, say, a socket read is aborted?  And if it's not
> abortable, how does one work around that fact?

Ah, such a good question.  The quick answer is that one does not depend on
the use of aborts when doing socket programing ;)  Actually according to
winsock if you close the socket while another task is block on it waiting
for a read it will return a from the read function with an error.  So if you
want to shutdown you socket servers close your sockets and then abort your
tasks.

> Or suppose one task does a socket read, and another task gets aborted.
> How well does that work?  On windows, I mean.  Assume polling is turned
> on.

This works well since the tasks are mapped to native threads so the other
thread is free to poll away for the abort.  Now I must say I am by no means
an expert on the gnat compiler; my source diving has been limited to the
parser and the Text_IO implementation.  My information on tasking is based
on empirical experience, the gnat documentation and a few comments I think I
remember Dr. Dewar making on CLA ;)

-CRM

Re: tasking with GNAT 3.14p on windows

[Jano]

Chad R. Meiners dice...
> 
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcck7ef9bzv.fsf@shell01.TheWorld.com...
> >
> > The Ada RM has nothing to say about system calls, so of course they are
> > not guaranteed (by the RM) to be abortable.  But I'm very interested in
> > what GNAT does with system calls in the presence of abort.  Can you tell
> > us what happens if, say, a socket read is aborted?  And if it's not
> > abortable, how does one work around that fact?
> 
> Ah, such a good question.  The quick answer is that one does not depend on
> the use of aborts when doing socket programing ;)  Actually according to
> winsock if you close the socket while another task is block on it waiting
> for a read it will return a from the read function with an error.  So if you
> want to shutdown you socket servers close your sockets and then abort your
> tasks.

Indeed, I think AWS does that: it closes sockets from a watchdog task 
while blocked for I/O in another. 

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: tasking with GNAT 3.14p on windows

[Pascal Obry]

Jano <nono@celes.unizar.es> writes:

> Indeed, I think AWS does that: it closes sockets from a watchdog task 
> while blocked for I/O in another. 

Right, see AWS.Server.Line_Cleaner task for example.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: tasking with GNAT 3.14p on windows

[Dmitry A. Kazakov]

On 31 Mar 2003 21:40:04 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>"Chad R. Meiners" <crmeiners@hotmail.com> writes:
>
>> "Jano" <nono@celes.unizar.es> wrote in message
>> news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE...
>> > trying to know the behavior with blocking I/O. In XP with -gnatP, you
>> > get indefinite wait for user input, but if more than 10 seconds has
>> > passed when you hit enter, you get also the "aborted" print.
>> >
>> > Is that expected behavior? Gnat docs say that polling implements calls
>> > in each loop iteration / function call. Should I assume that if you
>> > haven't loops / calls, abort will never work properly?
>> 
>> It seems like reasonable behavior.  System calls are not guaranteed to be
>> abortable.
>
>The Ada RM has nothing to say about system calls, so of course they are
>not guaranteed (by the RM) to be abortable.  But I'm very interested in
>what GNAT does with system calls in the presence of abort.  Can you tell
>us what happens if, say, a socket read is aborted?  And if it's not
>abortable, how does one work around that fact?

The single solution I know is to close the socket from another task.
This causes the pending operation to complete with an error so that
the reader task might then accept a rendezous. But this is of course
not an asynchronous control transfer.

If sockets some time will be included into the standard library, then
RM should require that all blocking socket operations be abortable and
in a bounded time.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: tasking with GNAT 3.14p on windows

[Alfred Hilscher]

"Dmitry A. Kazakov" schrieb:
> The single solution I know is to close the socket from another task.
> This causes the pending operation to complete with an error so that
> the reader task might then accept a rendezous. 

On Windows you can call WSACancelBlockingCall to unblock all blocking
socket calls.

--
-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------