gnat: time-slicing

gnat: time-slicing

[Jan Prazak]

Hello,

I have seen this example program in a tutorial:

------------
with Ada.Text_IO; use Ada.Text_IO;

procedure Task_Demo is
  task A;
  task body A is
  begin
    Put_Line("b");
    Put_Line("b");
  end A;
begin
  Put_Line("a");
  Put_Line("a");
end Task_Demo;
---------------

The output is:
a
a
b
b

But I want the output to be:

ab

ab

(the tutorial says that this is the output with enabled time-slicing)

I have tried to use -gnatT100, and -gnatT1, and pragma
Time_Slice(0.000001) etc., but none of this works.
I have gnat for Linux.

Jan

Re: gnat: time-slicing

[Dale Stanbrough]

Jan Prazak wrote:


> 
> But I want the output to be:
> 
> ab
> 
> ab
> 
> (the tutorial says that this is the output with enabled time-slicing)

The solution is to then do...

   Put_Line ("ab");
   New_Line;
   Put_Line ("ab");

Seriously, this is the answer if you want a particular ordering. 
If you aren't concerned about the exact ordering (and you program
should be independent of the ordering) then the previous is aok.

If you want to -test- it with different orderings to see how
your program will cope, then you could try putting in...

   random_delay (scale_factor);

which you will have to write, and will delay for a time from 
0.0..scale_factor seconds.

Dale

Re: gnat: time-slicing

[Jan Prazak]

On Mon, 15 Jul 2002 07:44:13 -0100, Dale Stanbrough wrote:

> The solution is to then do...
> 
>    Put_Line ("ab");
>    New_Line;
>    Put_Line ("ab");

This looks like a joke:)
The source code was just an example of using tasks, and both tasks have
to run at the same time. See also my reply to the reply by David C. Hoos.

> If you want to -test- it with different orderings to see how your
> program will cope, then you could try putting in...
> 
>    random_delay (scale_factor);
> 
> which you will have to write, and will delay for a time from
> 0.0..scale_factor seconds.

Where should this be placed? This looks like the suggestions from David,
he suggested "Delay 0.02" after each Put_Line, but it gives not the
result I want.

Think of a timer:

task Timer is ...
...
loop
  Delay 1.0;
  Put(current_time);
end loop;
...

The task uses one Put, which puts current time somewhere on the screen.
And this task has to be completely independent from other tasks (= main
procedure). There has to be a way to do this with gnat, and that's also
my question. I don't want to slow down other tasks with "Delay", just to
let Timer-task do the next step (for example when doing some difficult
computing, maybe array-sorting or similar things), so there has to be a
"direct" way (like a pragma).

Thanks,
Jan

Re: gnat: time-slicing

[David C. Hoos]

----- Original Message -----
From: "Jan Prazak" <janp9@gmx.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, July 15, 2002 2:10 PM
Subject: Re: gnat: time-slicing


<snip>
> Where should this be placed? This looks like the suggestions from David,
> he suggested "Delay 0.02" after each Put_Line, but it gives not the
> result I want.
What result did it give?

When I ran your program on my RedHat 6.2 box with dual 1.0 gHz. processors,
it gave the result you wanted.

When I ran it on my Win2K box with one 1.8 gHz. processor, it gave the reult
a
a
b
b

When I added the suggested delay statements, it gave the result
b
a
b
a

which interleaves the actions of the tasks, but with Task_A beginning
execution before the main program.

There is no way your program can be deterministic over different
OSs, and hardware platforms.  Time slicing will not do it either.

>
> Think of a timer:
>
> task Timer is ...
> ...
> loop
>   Delay 1.0;
>   Put(current_time);
> end loop;
> ...
>
> The task uses one Put, which puts current time somewhere on the screen.
> And this task has to be completely independent from other tasks (= main
> procedure). There has to be a way to do this with gnat, and that's also
> my question. I don't want to slow down other tasks with "Delay", just to
> let Timer-task do the next step (for example when doing some difficult
> computing, maybe array-sorting or similar things), so there has to be a
> "direct" way (like a pragma).
This restatement of what you want to do is completely different from what
you described in your original post.

If I understand what you want is a task that will run once per some time
interval
independently of the other task(s).

Here is an example of how that can be done:

   Interval : constant Duration := 1.0;
   use type Ada.Calendar.Time;
   Next_Time : Ada.Calendar.Time :=
       Ada.Calendar.Clock + Interval;
begin
    loop
        Delay until Next_Time;
        Next_Time := Next_Time + Interval;
        ......
   end loop;


Since delays are for a _minimum_ of the specified time, using a simple
delay statement in a "timer" will result in an accumulation of time error.

What I have shown above will put the task on the ready queue for its
priority at precisely Interval-second intervals without accumulation of
time errors.

However, just how soon after the task becomes ready it will actually
run depends on what other tasks are running, their priorities relative to
the priority of the "timer" task, and whether these other tasks are
"civilized" about yielding the CPU from time-to-time if they are compute-
intensive.

For example, if you have a compute-intensive task that executes a
delay 0.0 statement no time will be lost if there is no other task ready
to run.  But, when your timer task is ready, and is of a higher priority,
it will run when given the opportunity.

Re: gnat: time-slicing

[Jan Prazak]

On Mon, 15 Jul 2002 16:16:17 -0100, David C. Hoos wrote:

> What result did it give?
> 
> When I ran your program on my RedHat 6.2 box with dual 1.0 gHz.
> processors, it gave the result you wanted.
> 
> When I ran it on my Win2K box with one 1.8 gHz. processor, it gave the
> reult a
> a
> b
> b

the result was
a
b
a
b

with Delay 0.01 after *every* Put_Line
and 

a
a
b
b

with no delays.

The tutorial mentions, that

ab

ab

can be produced even on systems with only one CPU, depending on the
compiler.

> When I added the suggested delay statements, it gave the result b a
> b
> a
> 
> which interleaves the actions of the tasks, but with Task_A beginning
> execution before the main program.

Task_A begins after the main program in my case.

> There is no way your program can be deterministic over different OSs,
> and hardware platforms.  Time slicing will not do it either.

Yes, let us close this topic. I have what I want, because the test
program with task "Beep" works as expected (I want to make a similar
program).

>> Think of a timer:
>>
>> task Timer is ...
>> ...
>> loop
>>   Delay 1.0;
>>   Put(current_time);
>> end loop;
>> ...
> This restatement of what you want to do is completely different from
> what you described in your original post.

I don't think so. It's different, but not at all.
Let me discuss my "Beep" program.In my first posting,
there is Put_Line, which lets execute another statements (tasks) only
when it has finished writing the text ('a'), and so I expected "Get(C)"
also to stop all running processes, until the user gives a character and
presses enter. But actually it permits other tasks to run at the same
time, which I haven't expected.

> If I understand what you want is a task that will run once per some time
> interval
> independently of the other task(s).

yes, for instance

> Here is an example of how that can be done:
> 
>    Interval : constant Duration := 1.0;
>    use type Ada.Calendar.Time;
>    Next_Time : Ada.Calendar.Time :=
>        Ada.Calendar.Clock + Interval;
> begin
>     loop
>         Delay until Next_Time;
>         Next_Time := Next_Time + Interval;
>         ......
>    end loop;

This looks like an example from the Ada95 reference manual.

> For example, if you have a compute-intensive task that executes a delay
> 0.0 statement no time will be lost if there is no other task ready to
> run.  But, when your timer task is ready, and is of a higher priority,
> it will run when given the opportunity.

As I could see, "Delay 0.0" is ignored by the compiler (running program).
It has no effects on other tasks. I have tried to add "Delay 0.0" after each
"Put_Line" into the first example program, and the result was
a
a
b
b

(same as with no delays).
Maybe there is something like "if Duration = 0.0 then skip_statement" in the
definition of Delay.

---
Thanks,
Jan

Re: gnat: time-slicing

[Jan Prazak]

The problem is solved now, see my reply, 23:30 h.

Re: gnat: time-slicing

[Lutz Donnerhacke]

* Jan Prazak wrote:
>The tutorial mentions, that
>
>ab
>
>ab
>
>can be produced even on systems with only one CPU, depending on the
>compiler.

First you need a OS able to perform a task switch while performing system IO.
Most multitasking OS do not do this. While performing a system call, this
call can not interrupted by normal tasking.

Re: gnat: time-slicing

[Aaro Koskinen]

lutz@iks-jena.de (Lutz Donnerhacke) writes:
> * Jan Prazak wrote:
> >The tutorial mentions, that
> >
> >ab
> >
> >ab
> >
> >can be produced even on systems with only one CPU, depending on the
> >compiler.
> 
> First you need a OS able to perform a task switch while performing system IO.
> Most multitasking OS do not do this. While performing a system call, this
> call can not interrupted by normal tasking.

It's also a question of I/O buffering. I'm not sure if GNAT libraries
use libc for I/O in Linux, but if they do, then the default buffering
mode for stdout is "line buffering", i.e. each line is written using a
single system call. It is possible to turn I/O buffering off, which
results in a system call for each character - and this would allow a
task switch between each character.

A.

-- 
Aaro Koskinen
E-mail: aaro@iki.fi            "I'm the ocean, I'm the giant undertow."
http://www.iki.fi/aaro

Re: gnat: time-slicing

[SteveD]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnaj7uc6.oq.lutz@taranis.iks-jena.de...
>
> First you need a OS able to perform a task switch while performing system
IO.
> Most multitasking OS do not do this. While performing a system call, this
> call can not interrupted by normal tasking.

I would say that the exact opposite is true.  Most multitasking OS do task
switching while performing system IO.  But I suppose it depends on what you
mean by "performing system IO".

I/O devices tend to be slow.  Typically I/O requests are queued to a driver.
The driver actually performs the I/O.  A common technique is for serial
drivers is for the I/O request to enter data into a ring buffer and trigger
the driver to start transmitting.  The driver sends the first block of
characters from the ring buffer and then relinquishes control back to the
scheduler (permitting tasks to run).  The serial device generates an
interrupt when the transmit buffer is empty triggering the driver to send
the next block of characters from the ring buffer.  This continues until the
ring buffer is empty.

Whether or not characters are interleaved when the program does a "Put_Line"
depends on whether characters are added to the ring buffer one at a time or
as a block.

Whether or not you program continues executing after data is queued to I/O
or when the I/O is complete depends on the OS and implementation of the
driver.

SteveD

Re: gnat: time-slicing

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> First you need a OS able to perform a task switch while performing
> system IO.  Most multitasking OS do not do this. While performing a
> system call, this call can not interrupted by normal tasking.

Threading libraries (maybe except GNU Pth) for such systems usually
change all I/O system calls (in fact, section 2 libc routines) into
non-blocking callls, so that they can schedule during I/O.

Re: gnat: time-slicing

[Marin David Condic]

It sounds like you are looking for some way of controlling the scheduling
algorithm. Some compilers use some version of a "run until blocked"
algorithm and the "blocked" part won't necessarily happen where you'd like
it to (such as on an I/O statement). Some implementations might give you the
ability to select some flavor of round-robin timeslicing as the means of
scheduling. That would give you more of a "fair share" situation, but won't
necessarily give you deterministic behavior from your program. If you don't
need determinism, this may be a viable option. You need to investigate your
compiler documentation to see if you can do anything to specify the
scheduling algorithm to use.

Check out Annex D or the ARM very carefully & you might find some useful
information there about scheduling and priorities. Tasking is one of the
more complicated features of Ada and I regularly find myself having to go
back to the ARM and re-learn how to do it. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.15.16.20.47.38263.1135@gmx.net...
>
> The task uses one Put, which puts current time somewhere on the screen.
> And this task has to be completely independent from other tasks (= main
> procedure). There has to be a way to do this with gnat, and that's also
> my question. I don't want to slow down other tasks with "Delay", just to
> let Timer-task do the next step (for example when doing some difficult
> computing, maybe array-sorting or similar things), so there has to be a
> "direct" way (like a pragma).
>

Re: gnat: time-slicing

[Jan Prazak]

On Tue, 16 Jul 2002 12:29:07 -0100, Marin David Condic wrote:

> Check out Annex D or the ARM very carefully & you might find some useful
> information there about scheduling and priorities. Tasking is one of the
> more complicated features of Ada and I regularly find myself having to
> go back to the ARM and re-learn how to do it. :-)

Yes, tasking has a simple and a difficult side. But for now I don't need
to go into details, because I am planning to do just the simple things.

Re: time-slicing

[David C. Hoos]

Putting a delay statement (e.g. delay 0.02;)
after each Put_Line statement will cause the
task to yield the CPU for at least the specified time,
thereby interleaving the tasks' execution.

----- Original Message ----- 
From: "Jan Prazak" <janp9@gmx.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, July 15, 2002 6:25 AM
Subject: gnat: time-slicing


> Hello,
> 
> I have seen this example program in a tutorial:
> 
> ------------
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Task_Demo is
>   task A;
>   task body A is
>   begin
>     Put_Line("b");
>     Put_Line("b");
>   end A;
> begin
>   Put_Line("a");
>   Put_Line("a");
> end Task_Demo;
> ---------------
> 
> The output is:
> a
> a
> b
> b
> 
> But I want the output to be:
> 
> ab
> 
> ab
> 
> (the tutorial says that this is the output with enabled time-slicing)
> 
> I have tried to use -gnatT100, and -gnatT1, and pragma
> Time_Slice(0.000001) etc., but none of this works.
> I have gnat for Linux.
> 
> Jan
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: time-slicing

[Ian Broster]

> Putting a delay statement (e.g. delay 0.02;)
> > ------------
> > with Ada.Text_IO; use Ada.Text_IO;
> > 
> > procedure Task_Demo is
> >   task A;
> >   task body A is
> >   begin
> >     Put_Line("b");
> >     Put_Line("b");
> >   end A;
> > begin
> >   Put_Line("a");
> >   Put_Line("a");
> > end Task_Demo;
> > ---------------

Relying on assumptions about scheduling decisions generally a bad idea-
it may work on a minimal program, but it's very fragile. Change something
else and you have no guarantees of what might happen.

If you need to ensure synchronisation, use some synchronisation
mechanisms like a rendezvous or a protected object.


ian

Re: time-slicing

[Jan Prazak]

I have modified the code a bit, and this two tasks run surprisingly at
the same time. While the main task waits for a key+enter, the second task
is running! Tasks seem to be more complicated than I thought.

-------
with Ada.Text_IO, Ada.Characters.Latin_1;
use Ada.Text_IO, Ada.Characters.Latin_1;

procedure Task_Demo is

  task Beep is
    entry Shut_Down;
  end Beep;

  task body Beep is
   Break_Loop : Boolean := False;
  begin
    loop
       select
         accept Shut_Down
         do
           Break_Loop := True;
         end Shut_Down;
       or
         Delay 2.0;
         Put(BEL);
       end select;

       exit when Break_Loop;
    end loop;
  end Beep;

C : Character;
begin
  New_Line;
  Put("Enter a character: ");
  Get(C); Skip_Line;
  New_Line;
  Beep.Shut_Down;
end Task_Demo;[

Re: time-slicing

[Jan Prazak]

On Mon, 15 Jul 2002 12:07:10 -0100, David C. Hoos wrote:

> Putting a delay statement (e.g. delay 0.02;) after each Put_Line
> statement will cause the task to yield the CPU for at least the
> specified time, thereby interleaving the tasks' execution.

That sounds good, but it has not the right result. The output is

----
a
b
a
b
----

because the commands are still not running simultaneously. Each command
seems to wait until a running command (Put_Line) has finished.
The tutorial says that there has to be a pragma, which enables
time-slicing (and time-slicing is definitely disabled in gnat),
when the output is not

----
ab

ab

----

Maybe gnat doesn't even support time-slicing, but there is a command line
switch and also a pragma (but as I have said, both unfortunately don't
work).
But actually I don't need this at the moment, it was just a question.

Re: time-slicing

[Anders Gidenstam]

In article <pan.2002.07.15.16.01.11.552776.1135@gmx.net>,
	Jan Prazak <janp9@gmx.net> writes:
> Maybe gnat doesn't even support time-slicing, but there is a command line
> switch and also a pragma (but as I have said, both unfortunately don't
> work).
> But actually I don't need this at the moment, it was just a question.

Hi,

I think the time-slice is a lot longer than the time it takes to call
Put_Line twice, so it is quite unlikely that you will get a task switch
in the middle.

The following small program may give you some idea on how much work
your computer actually manages to do during one time-slice.. and it
will also show whether your gnat installation does time-slicing or
not.
(I certainly expects it does, with the standard Ada runtime library
for Linux tasks are mapped to Linux threads and those are time-sliced
by default.)

with Ada.Text_IO;
procedure Task_Test is

   task type Writer (C : Character);
   task body Writer is
   begin
      loop
         Ada.Text_IO.Put (C);
      end loop;
   end Writer;

   A : Writer ('A');
   B : Writer ('B');
begin
   null;
end Task_Test;

/Anders
-- 
--------------------------------------------
"A well-written program is its own heaven; 
 a poorly-written program is its own hell."
  - The Tao of Programming 

Re: time-slicing

[Jan Prazak]

On Mon, 15 Jul 2002 18:05:58 -0100, Anders Gidenstam wrote:

> Hi,
> 
> I think the time-slice is a lot longer than the time it takes to call
> Put_Line twice, so it is quite unlikely that you will get a task switch
> in the middle.

This is an interesting theory.

> with Ada.Text_IO;
> procedure Task_Test is
> 
>    task type Writer (C : Character);
>    task body Writer is
>    begin
>       loop
>          Ada.Text_IO.Put (C);
>       end loop;
>    end Writer;
> 
>    A : Writer ('A');
>    B : Writer ('B');
> begin
>    null;
> end Task_Test;

Yes, this really supports your theory. The output is at least 400*'A',
then 400*'B', 400*'A' and so on. So one time-slice is long enough to
execute 400 statements. So now there is only one question: how to change
the duration? But I suppose that it's not very neccessary to change it.

thanks,
Jan

Re: time-slicing

[Darren New]

Jan Prazak wrote:
> So now there is only one question: how to change
> the duration? 

If you need to ask that question, chances are you've made a mistake in your
design somewhere.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

 Proud to live in a country where "fashionable" 
     is denim, "stone-washed" faded, with rips.

Re: time-slicing

[Pascal Obry]

Jan Prazak <janp9@gmx.net> writes:

> On Mon, 15 Jul 2002 18:05:58 -0100, Anders Gidenstam wrote:
> 
> > Hi,
> > 
> > I think the time-slice is a lot longer than the time it takes to call
> > Put_Line twice, so it is quite unlikely that you will get a task switch
> > in the middle.
> 
> This is an interesting theory.

This is not theory and certainly the best answer so far for this problem :)


Why on earth should the time-slicing occurs between both Put_Line ?????

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: time-slicing

[Jan Prazak]

On Tue, 16 Jul 2002 15:30:26 -0100, Pascal Obry wrote:

> This is not theory and certainly the best answer so far for this problem
> :)

yes, indeed

> Why on earth should the time-slicing occurs between both Put_Line ?????

It's just an example program from a tutorial, so don't think about such
questions...

Re: time-slicing

[Robert Dewar]

Jan Prazak <janp9@gmx.net> wrote in message news:<pan.2002.07.15.16.01.11.552776.1135@gmx.net>...

> The tutorial says that there has to be a pragma, which 
> enable time-slicing 

This is also false, perhaps it is time to get another 
tutorial. If it really says this it is wrong. There is
no required support for time slicing in Ada 95. The only
required scheduling discipline is run till blocked, and
that is only required if you use the proper pragma and
annex D is supported.

On a system like GNU/Linux or NT, you will get whatever the underlying
threads mechanism provides. You did not
even say which threads package you were using on your
system.

Re: gnat: time-slicing

[tmoran]

> But I want the output to be:
>
> ab
>
> ab
>
  So you not only want time-slicing, you want it to occur during the two
'Put_Line("a");'s, but not during the 'Put_Line("B");'s, in fact after the
'a' has been output and before the crlf, and you want Text_IO to be
reentrant in the sense that two writes to the same file can interleave
without screwing up.  That's asking for quite a lot.
  As has been pointed out, if you want to control task switching you can
do it with "delay 0.0;" or other explicit task switching commands.  If
you leave it up to the particular OS on the particular computer on the
particular day running the particular load you happen to hit, you'll just
have to take whatever you get.
  You may want to try running Timetest, see www.adapower.com/reuse/tt.html

Re: gnat: time-slicing

[Jan Prazak]

On Mon, 15 Jul 2002 20:03:29 -0100, tmoran wrote:

>   You may want to try running Timetest, see
>   www.adapower.com/reuse/tt.html

I will take a look at it, thanks.

Re: gnat: time-slicing

[Robert Dewar]

Jan Prazak <janp9@gmx.net> wrote in message news:<pan.2002.07.15.10.24.43.431977.7868@gmx.net>...
> Hello,
> 
> I have seen this example program in a tutorial:
> 
> ------------
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Task_Demo is
>   task A;
>   task body A is
>   begin
>     Put_Line("b");
>     Put_Line("b");
>   end A;
> begin
>   Put_Line("a");
>   Put_Line("a");
> end Task_Demo;

This is a nonsense example, it is erroneous to do output
on the same file from two different tasks, since obviously
the file is a shared variable, and the program violates
rules about access to shared variables. You must always
properly control access of tasks to I/O. If the compiler
deleted your hard disk when you ran this program, you
could decide that it was an unpleasant compiler to use,
but not that it was an incorrect compiler (erroneous
programs have completely undefined semantics).

All the discussion about time slicing is besides the point
given this observation.

Re: gnat: time-slicing

[Jan Prazak]

On Tue, 16 Jul 2002 20:29:48 -0100, Robert Dewar wrote:


> This is a nonsense example, it is erroneous to do output on the same
> file from two different tasks, since obviously the file is a shared
> variable, and the program violates rules about access to shared

There is no output to a file. And I think it's an interesting example (if
it works as explained in the tutorial), because it shows that tasking can
be dangerous in some way.

Re: gnat: time-slicing

[Pascal Obry]

Jan Prazak <janp9@gmx.net> writes:

> On Tue, 16 Jul 2002 20:29:48 -0100, Robert Dewar wrote:
> 
> 
> > This is a nonsense example, it is erroneous to do output on the same
> > file from two different tasks, since obviously the file is a shared
> > variable, and the program violates rules about access to shared
> 
> There is no output to a file.

Standard output is a file.

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: gnat: time-slicing

[Jan Prazak]

On Wed, 17 Jul 2002 15:44:24 -0100, Pascal Obry wrote:



>> There is no output to a file.
> 
> Standard output is a file.

But Put_Line does not write to standard output, you would have to specify
a file as a parameter.

Re: gnat: time-slicing

[Randy Brukardt]

Jan Prazak wrote in message ...
>On Wed, 17 Jul 2002 15:44:24 -0100, Pascal Obry wrote:
>
>
>
>>> There is no output to a file.
>>
>> Standard output is a file.
>
>But Put_Line does not write to standard output, you would have to
specify
>a file as a parameter.

When you don't specify a file parameter to Put_Line, it writes to
Current_Output which, if you haven't changed it, is Standard_Output.
Text_IO *always* writes to a file. Duh.

       Randy.

Re: gnat: time-slicing

[Jan Prazak]

On Wed, 17 Jul 2002 18:21:58 -0100, Randy Brukardt wrote:


>>>> There is no output to a file.
>>>
>>> Standard output is a file.
>>
>>But Put_Line does not write to standard output, you would have to
> specify
>>a file as a parameter.
> 
> When you don't specify a file parameter to Put_Line, it writes to
> Current_Output which, if you haven't changed it, is Standard_Output.
> Text_IO *always* writes to a file. Duh.

If it's true, then the Linux console/terminal is a file. Duhuhuh. :)
No, seriously, explain it a bit more. As far as I know, a terminal is a
device in Linux, which is some kind of a file, maybe you mean this. When
I run the program in konsole (KDE xterm), the output is on the screen,
and that's logical, because I haven't specified a file in Put_Line.

Re: gnat: time-slicing

[Marin David Condic]

Terminology problems here. You are thinking of a "file" as a file-system
file that resides on a disk with permanence, etc. Ada thinks of a "file" as
sort of a logical thing - the ultimate destination of the data being
something beyond the scope of the language. (Could be a terminal or disk
file or paper-tape or network pipe or whatever...) So to Ada the console is
a file. (Not surprisingly, Unix kind of likes to think of all its device
drivers as files, so it isn't as if Ada invented something new.)

So from a logical perspective, the "file" (in the sense of an
Ada.Text_IO.File_Type object) is a "variable" ("object" in Ada parlance) and
if you are accessing the same variable from two tasks (which you do
implicitly with Put_Line, since the default is to use an object denoted by
the function Current_Output) this could be A Bad Thing. Accessing a shared
variable from two threads of control is going to result in unpredictable
behavior unless you do something to explicitly control the access. If you
hide the Put_Line subprogram behind your own Put_Line subprogram that exists
inside a protected object, you can guarantee that the tasks have to get in
line and wait their turn to access the shared output file.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.17.21.38.14.849546.1934@gmx.net...
>
> If it's true, then the Linux console/terminal is a file. Duhuhuh. :)
> No, seriously, explain it a bit more. As far as I know, a terminal is a
> device in Linux, which is some kind of a file, maybe you mean this. When
> I run the program in konsole (KDE xterm), the output is on the screen,
> and that's logical, because I haven't specified a file in Put_Line.
>

Re: gnat: time-slicing

[Larry Kilgallen]

In article <ah4i85$n80$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> if you are accessing the same variable from two tasks (which you do
> implicitly with Put_Line, since the default is to use an object denoted by
> the function Current_Output) this could be A Bad Thing. Accessing a shared
> variable from two threads of control is going to result in unpredictable
> behavior unless you do something to explicitly control the access.

Or unless you have a guarantee from the Ada implementation or the
operating system in that regard.

Re: gnat: time-slicing

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<YO$4QirEkuiT@eisner.encompasserve.org>...

> Or unless you have a guarantee from the Ada implementation or the
> operating system in that regard.

In my view it is dubious for an Ada implementation to guarantee the
behavior of an erroneous program, and it is even more dubious for
a program to rely on such a guarantee. No competent Ada programmer
should ever write erroneous code except in very rare and very well
documented situations, and even there it is almost always better to
find another solution.

For example, if you write erroneous code, a new version of the compiler
may change the behavior, and you have no basis to complain. Moreover
if you have to port the code to another compiler you can get into very
nasty trouble. It is one thing to rely on implementation defined
behavior (which can of course also cause portability difficulties,
but of a much better defined kind) and quite another to rely on
erroneous code.

Re: gnat: time-slicing

[Pascal Obry]

Jan Prazak <janp9@gmx.net> writes:

> On Wed, 17 Jul 2002 15:44:24 -0100, Pascal Obry wrote:
> >> There is no output to a file.
> > 
> > Standard output is a file.
> 
> But Put_Line does not write to standard output, you would have to specify
> a file as a parameter.

If it does not write to standard output, where the output goes ? I think
you should read the documentation :)

Of course Put_Line does write to standard output (stdout if you come from
the C/C++ world) !

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: gnat: time-slicing

[Jan Prazak]

On Wed, 17 Jul 2002 18:43:12 -0100, Pascal Obry wrote:

> If it does not write to standard output, where the output goes ? I think
> you should read the documentation :)

If it writes to standard output, then standard output is the screen (at
least in my case) by default.

> Of course Put_Line does write to standard output (stdout if you come
> from the C/C++ world) !

Fortunately I don't come from the C world, but I have read a C++ tutorial
(long time ago), so I have read about stdout there (as far as I can
remember, output is done with >> in C++, and input with <<, or something
like this, that's also similar to > and < in Linux shell).

Re: gnat: time-slicing

[Pascal Obry]

Jan Prazak <janp9@gmx.net> writes:

> Fortunately I don't come from the C world, but I have read a C++ tutorial
> (long time ago), so I have read about stdout there (as far as I can
> remember, output is done with >> in C++, and input with <<, or something
> like this, that's also similar to > and < in Linux shell).

And in C/C++ file descriptors 0, 1 and 2 are... stdin, stdout and stderr :)
These are equivalent to Standard_Input, Standard_Output and Standard_Error 
in Ada.

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: gnat: time-slicing

[Pascal Obry]

Jan Prazak <janp9@gmx.net> writes:

> On Wed, 17 Jul 2002 18:43:12 -0100, Pascal Obry wrote:
> 
> > If it does not write to standard output, where the output goes ? I think
> > you should read the documentation :)
> 
> If it writes to standard output, then standard output is the screen (at
> least in my case) by default.

A screen !?! Well a file descriptor that map the data stream to the screen
using a low level device driver... Same for keyboard.

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: gnat: time-slicing

[chris.danx]

"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.17.20.38.35.826272.1851@gmx.net...
> On Wed, 17 Jul 2002 15:44:24 -0100, Pascal Obry wrote:
>
>
>
> >> There is no output to a file.
> >
> > Standard output is a file.
>
> But Put_Line does not write to standard output, you would have to specify
> a file as a parameter.

Since you're familiar with Pascal, it is roughly the same as WriteLn and
should be *no problem* for you.

WriteLn ('some string');

writes to standard output, while

WriteLN ('some string', somefile);

writes to a file.

As in Ada (but perhaps no to the same extent as in Ada), files are logical
entities in Pascal, not physical entities.  Consider Turbo Pascal where you
could send output to a printer by regarding it as a file, though a printer
is in reality a physical device.


Chris

Re: gnat: time-slicing

[R. Tim Coslet]

Tasking is always potentially "dangerous"!!!

That is why Ada provides the features it does to coordinate Tasks (e.g.,
Protected Objects, requeue, abort, entry calls) and keep them from stepping
on each other's data structures.

But no Tasking system (Ada or not) can ever be fully deterministic in what
runs when!

-- 
        R. Tim Coslet
        r_tim_coslet@pacbell.net

Technology, n. Domesticated natural phenomena.


> From: Jan Prazak <janp9@gmx.net>
> Newsgroups: comp.lang.ada
> Date: Wed, 17 Jul 2002 18:29:25 -0100
> Subject: Re: gnat: time-slicing
> 
> On Tue, 16 Jul 2002 20:29:48 -0100, Robert Dewar wrote:
> 
> 
>> This is a nonsense example, it is erroneous to do output on the same
>> file from two different tasks, since obviously the file is a shared
>> variable, and the program violates rules about access to shared
> 
> There is no output to a file. And I think it's an interesting example (if
> it works as explained in the tutorial), because it shows that tasking can
> be dangerous in some way.
> 

Re: gnat: time-slicing

[SteveD]

"R. Tim Coslet" <R_Tim_Coslet@pacbell.net> wrote in message
news:B95B79D3.4951%R_Tim_Coslet@pacbell.net...
> Tasking is always potentially "dangerous"!!!
>
> That is why Ada provides the features it does to coordinate Tasks (e.g.,
> Protected Objects, requeue, abort, entry calls) and keep them from
stepping
> on each other's data structures.

I fully agree with this.

> But no Tasking system (Ada or not) can ever be fully deterministic in what
> runs when!

I disagree with this.  It is possible to have a fully deterministic tasking
system.  This is reasonably easy to demonstrate with synchronous tasking.  I
don't believe such systems are common, but they do exist.

SteveD

> --
>         R. Tim Coslet
>         r_tim_coslet@pacbell.net
>
> Technology, n. Domesticated natural phenomena.

Re: gnat: time-slicing

[Robert Dewar]

"R. Tim Coslet" <R_Tim_Coslet@pacbell.net> wrote in message news:<B95B79D3.4951%R_Tim_Coslet@pacbell.net>...
> Tasking is always potentially "dangerous"!!!
> 
> That is why Ada provides the features it does to coordinate Tasks (e.g.,
> Protected Objects, requeue, abort, entry calls) and keep them from stepping
> on each other's data structures.
> 
> But no Tasking system (Ada or not) can ever be fully deterministic in what
> runs when!

That's really very misleading. It is of course possible to write
deterministic
tasking programs, even using only the core language with undefined
dispatching
semantics. If you are using an Annex D compiler with the appropriate
pragmas,
on a monoprocessor, the semantics are designed to be (and are) almost
completely deterministic. The above statement reflects some pretty
significant misunderstanding.

Re: gnat: time-slicing

[Frank J. Lhota]

"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.17.18.15.32.366460.1723@gmx.net...

> There is no output to a file. And I think it's an interesting example (if
> it works as explained in the tutorial), because it shows that tasking can
> be dangerous in some way.

The fact that "tasking can be dangerous in some way" is common knowledge.
Moreover, most programmers who have done tasking / multithreading should
spot the error in this example right away - two tasks are using the same
resource (current output) with no guards against concurrent access.

Re: gnat: time-slicing

[Robert A Duff]

Jan Prazak <janp9@gmx.net> writes:

> Hello,
> 
> I have seen this example program in a tutorial:
> 
> ------------
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Task_Demo is
>   task A;
>   task body A is
>   begin
>     Put_Line("b");
>     Put_Line("b");
>   end A;
> begin
>   Put_Line("a");
>   Put_Line("a");
> end Task_Demo;
> ---------------

The above example is erroneous, which means that the output is totally
unpredictable.  The reason it's erroneous is that two tasks are messing
with the same shared variable (the standard output file) at the same
time.  There's been a lot of confusing discussion about what a file is,
and whether this is a "device" or a "file" and so forth.  You're correct
in thinking that writing to standard output writes to the screen (by
default).  But that's all irrelevant.  The point is, you have two tasks
messing with the same variable (in this case, what Ada calls an
"internal file"), and that's wrong.

Note that "erroneous" is an Ada technical term.  It doesn't mean exactly
the same thing as it does in plain English (unfortunately).  Look it up
in the RM, if you like.

> The output is:
> a
> a
> b
> b
> 
> But I want the output to be:
> 
> ab
> 
> ab

It doesn't matter what you *want* -- this program could do *anything*,
since it's erroneous.  As Robert Dewar pointed out, it could erase your
entire hard disk.  Or, as the C folks like to put it, it might make
demons fly from your nose.

There's no standard Ada way to make this program do anything in
particular, because it is erroneous (i.e. unpredictable).

> (the tutorial says that this is the output with enabled time-slicing)

I haven't seen this tutorial.  Perhaps its point is that you can get
different outputs from erroneous programs, depending on compiler
switches.  Perhaps the author means that it is *possible* to get the
above output when time slicing is turned on (and perhaps some experiment
showed that to be true).  True, but there is certainly no way to
guarantee that output (in standard Ada).

I suspect the tutorial is confusing.  You shouldn't be trying to get
things to behave in a certain way by fiddling with compiler switches.
You should be writing code that obeys the rules (unlike the above
example), and therefore gives the results you want.

> I have tried to use -gnatT100, and -gnatT1, and pragma
> Time_Slice(0.000001) etc., but none of this works.
> I have gnat for Linux.
> 
> Jan

- Bob

Re: gnat: time-slicing

[Jan Prazak]

On Fri, 19 Jul 2002 01:33:13 -0100, Robert A Duff wrote:

> I suspect the tutorial is confusing.  You shouldn't be trying to get
> things to behave in a certain way by fiddling with compiler switches.
> You should be writing code that obeys the rules (unlike the above
> example), and therefore gives the results you want.

The tasking-example really seems to be confusing there, so I should
better forget what I've read...

Re: gnat: time-slicing

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
[...]
> Note that "erroneous" is an Ada technical term.  It doesn't mean exactly
> the same thing as it does in plain English (unfortunately).  Look it up
> in the RM, if you like.

That's one thing the C standard got right and the Ada standard got
wrong.  C's term for the same thing is "undefined behavior", which
means pretty much what is says in plain English; the standard defines
it more precisely, but the definition doesn't conflict with common
usage.  Ada's term "erroneous" is misleading because the word already
has a perfectly good meaning that's much less specific than the
meaning the Ada standard assigns to it.

On the other hand, of course, there's a lot more "undefined behavior"
in C than there is "erroneous execution" in Ada.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: gnat: time-slicing

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> [...]
> > Note that "erroneous" is an Ada technical term.  It doesn't mean exactly
> > the same thing as it does in plain English (unfortunately).  Look it up
> > in the RM, if you like.
> 
> That's one thing the C standard got right and the Ada standard got
> wrong.

I very much agree.  However, many C programmers don't understand the
concept, either.  Many programmers (in *any* language) think that the
language is defined by what the compiler at hand happens to do.
Experimental programming.

The best bet is to minimize the number of such cases in the language,
because we know that many programmers don't understand the concept, and
more importantly, even those who *do* understand can get it wrong by
accident.

>...C's term for the same thing is "undefined behavior", which
> means pretty much what is says in plain English; the standard defines
> it more precisely, but the definition doesn't conflict with common
> usage.  Ada's term "erroneous" is misleading because the word already
> has a perfectly good meaning that's much less specific than the
> meaning the Ada standard assigns to it.

Agreed.

> On the other hand, of course, there's a lot more "undefined behavior"
> in C than there is "erroneous execution" in Ada.

Right.  I think there's still too much of it in Ada, but Ada got it
mostly right.  Actually, I think there are so few cases, that you don't
need to refer to a technical term defined off in some faraway place --
you could include a lecture (two or three sentences) inline at each use
that explains how very evil indeed it is to rely on undefined behavior.

This isn't the only terminological mistake in Ada.  For example, if you
want to use a package, you don't use a use clause -- you use a with
clause.  And the RM says "mentioned in a with clause", which is too much
of a mouthful, so people end up using "with" as a verb, which is an
abominable abuse of the English language.

- Bob

Re: gnat: time-slicing

[Darren New]

Robert A Duff wrote:
> This isn't the only terminological mistake in Ada.  For example, if you
> want to use a package, you don't use a use clause -- you use a with
> clause.  And the RM says "mentioned in a with clause", which is too much
> of a mouthful, so people end up using "with" as a verb, which is an
> abominable abuse of the English language.

I suggest that instead of
   with MyPackage;
it be changed to
   use MyPackage;

Instead of
   with MyPackage; use MyPackage;
it be changed to
   use MyPackage alot;

;-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

 Proud to live in a country where "fashionable" 
     is denim, "stone-washed" faded, with rips.

Re: gnat: time-slicing

[Robert Dewar]

Keith Thompson <kst@cts.com> wrote in message news:<yecy9c7th59.fsf@king.cts.com>...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> [...]
> > Note that "erroneous" is an Ada technical term.  It doesn't mean exactly
> > the same thing as it does in plain English (unfortunately).  Look it up
> > in the RM, if you like.
> 
> That's one thing the C standard got right and the Ada standard got
> wrong.  C's term for the same thing is "undefined behavior", which
> means pretty much what is says in plain English; the standard defines
> it more precisely, but the definition doesn't conflict with common
> usage.  Ada's term "erroneous" is misleading because the word already
> has a perfectly good meaning that's much less specific than the
> meaning the Ada standard assigns to it.

To me undefined behavior is also a very vague term if we don't think
of
it as a technical term. Undeefined behavior can reasonably be thought
of
as encompassing four things in Ada:

  1. erroneous execution
  2. implementation defined behavior (and hence undefined in the
standard)
  3. implementation dependent behavior
  4. execution that is a bounded error (defined but still considered
wrong)

I actually like the use of the term erroneous as opposed to undefined,
but
in any case, the point is that both the terms undefined in C and
erroneous
in Ada are technical terms. In both cases you will get into trouble if
you
think of them as meaning just what they mean in English.

If you read a language standard, you must be prepared to acquire the
technical
terms that are used and understand them precisely. If you find that
too much
of a burden, then language standards are not for you. Now of course a
text book
or a tutorial is free to use any language it pleases. There is
certainly no
reason why every programmer should need to know precise technical
terms of
the standard, and it is unrealistic to think they will.

One of the rules we try to follow in GNAT error messages is NOT to
rely on the
precise meaning of technical terms. For example, everyone who reas the
standard
carefully knows that the term "package" does not include "generic
package". There are many statements in the RM that depend crucially on
this fact. But we
try to avoid a GNAT error message that uses the word "package" in this
formal
sense, since informally a generic package is a kind of package in
ordinary
english.

Similarly, what everyone calls a package specification, package spec
for short,
is in fact NOT a package specification at all in the RM, but rather a
package
declaration, and there are RM statements that depend on this
distinction, but
we try to avoid depending on this in error messages

(actually internally in the GNAT sources, and externally to some
extent, we
have defined package spec, which is a term that does not appear in the
RM,
to mean package declaration :-)

Re: gnat: time-slicing

[Keith Thompson]

dewar@gnat.com (Robert Dewar) writes:
[...]
> I actually like the use of the term erroneous as opposed to
> undefined, but in any case, the point is that both the terms
> undefined in C and erroneous in Ada are technical terms. In both
> cases you will get into trouble if you think of them as meaning just
> what they mean in English.

Hmm.  It's difficult to disagree with that, but somehow I manage to do
so.  8-)}

Yes, it's important to keep in mind that technical terms mean what the
standard says they mean, which doesn't necessarily match what they
mean in plain English.  It's also important for technical terms to be
chosen so as to minimize confusion.

Nobody is likely to use the phrase "undefined behavior" in anything
other than its technical meaning, or something very close to it.  The
technical meaning happens to be very close to its plain English
meaning.  Also, it's a phrase that people aren't likely to use
accidentally.

In contrast, I've heard people refer to Ada programs as "erroneous"
when they mean simply that they're incorrect.  When we discuss Ada, we
have to consciously delete the fairly common word "erroneous" from our
vocabularies, and replace it with the technical term.  The problem is
that the meaning of the technical term diverges too far from the
common meaning.

Finally, for whatever reason, there's a tendency to use the word
"erroneous" by itself, rather than in the phrase "erroneous execution"
(which is the technical term defined in the RM).  It's common, though
incorrect, to say that a piece of code is "erroneous".  (I *think*
this is partly the fault of imprecision in the Ada 83 RM, but I don't
have a copy handy.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: gnat: time-slicing

[Robert A Duff]

dewar@gnat.com (Robert Dewar) writes:

> I actually like the use of the term erroneous as opposed to undefined,
> but
> in any case, the point is that both the terms undefined in C and
> erroneous
> in Ada are technical terms. In both cases you will get into trouble if
> you
> think of them as meaning just what they mean in English.

Quite true.

However, I think it's a Good Thing to choose technical terms that don't
confuse people, in so far as that is possible.  I don't agree with
Humpty Dumpty. ;-)

There are two points that Ada's "erroneous" is trying to get across:

    - Don't do it; it's evil.
    
    - The program might do anything whatsoever.

Ada's "erroneous" captures the first.  C's "undefined behavior" captures
the second.  Can you think of an English phrase that captures both?

How about "undetected error"?  The "error" part of it captures the
first.  And the "undetected" heavily implies the second.

(Too many C programmers think "undefined behavior" means "experiment
with the current version of your current compiler, and see what it does;
depend on that".)

> If you read a language standard, you must be prepared to acquire the
> technical
> terms that are used and understand them precisely. If you find that
> too much
> of a burden, then language standards are not for you. Now of course a
> text book
> or a tutorial is free to use any language it pleases.

Therein lies danger.  If the textbook uses different terminology, then
people will be confused when they see the RM terminology.  Better to
choose the RM terminology so that it doesn't go "too wrong" when
interpreted loosely.

If programmer 1 walks up to programmer 2, and asks "Is this here thing
erroneous?", it would be Good if they understood each other without
explicitly defining their terms.

>... There is
> certainly no
> reason why every programmer should need to know precise technical
> terms of
> the standard, and it is unrealistic to think they will.

I think it's a sign of trouble when the language definition needs to do
that.

> One of the rules we try to follow in GNAT error messages is NOT to
> rely on the
> precise meaning of technical terms.

In most cases, that's a good thing.

>... For example, everyone who reas the
> standard
> carefully knows that the term "package" does not include "generic
> package". There are many statements in the RM that depend crucially on
> this fact. But we
> try to avoid a GNAT error message that uses the word "package" in this
> formal
> sense, since informally a generic package is a kind of package in
> ordinary
> english.

That one doesn't bother me so much.  In English, "adjective noun" is not
always a subset of "noun", and people generally understand that.  For
example, a "questionable fact" is not a "fact", a "pseudo intellectual"
is not quite an "intellectual", an "incorrect proof" is not a "proof",
an "illegal Ada program" is not an "Ada program".  Etc.

Surely everyone can see that a "generic elephant" is not a particular
elephant, but is a prototype of elaphantness (elaphanthood?).

> Similarly, what everyone calls a package specification, package spec
> for short,
> is in fact NOT a package specification at all in the RM, but rather a
> package
> declaration, and there are RM statements that depend on this
> distinction, but
> we try to avoid depending on this in error messages
> 
> (actually internally in the GNAT sources, and externally to some
> extent, we
> have defined package spec, which is a term that does not appear in the
> RM,
> to mean package declaration :-)

I like it, and I use term "spec" that way, but this clever obfuscation
wouldn't be necessary if the syntax rules were a little bit more
user-friendly.

- Bob

Erroneous execution? (was Re: gnat: time-slicing)

[Ben Brosgol]

> > with Ada.Text_IO; use Ada.Text_IO;
> >
> > procedure Task_Demo is
> >   task A;
> >   task body A is
> >   begin
> >     Put_Line("b");
> >     Put_Line("b");
> >   end A;
> > begin
> >   Put_Line("a");
> >   Put_Line("a");
> > end Task_Demo;
> > ---------------
>
> The above example is erroneous, which means that the output is totally
> unpredictable.  The reason it's erroneous is that two tasks are messing
> with the same shared variable (the standard output file) at the same
> time.

Bob-

Are you sure this is erroneous?  The "shared variable" is hidden in the
private part or body of a predefined library package and ARM paragraph A(3)
says that in such cases it is the responsibility of the implementation to
protect the shared variable from getting trashed (*).  Now Put_Line is
equivalent to looping over Put() and then doing a New_Line so the user may
see interspersed output -- e.g., either or both "b"s might not be
immediately followed by a newline -- but the implementation would be
nonconformant with the ARM if, for example, simultaneous calls on Put caused
the machine to reboot (which was the effect one saw in an early version of
the old Alsys DOS Ada compiler :-)

I'm not recommending that anyone actually write code such as Task_Demo, but
I don't think it's an example of erroneous execution.

(*) The rule actually says "The implementation shall ensure that each
language defined subprogram is reentrant in the sense that concurrent calls
on the same subprogram perform as specified, so long as all parameters that
could be passed by reference denote nonoverlapping objects."  But I believe
the intent is as I indicated.

-Ben

Re: Erroneous execution? (was Re: gnat: time-slicing)

[Robert A Duff]

"Ben Brosgol" <brosgol@world.std.com> writes:

> > > with Ada.Text_IO; use Ada.Text_IO;
> > >
> > > procedure Task_Demo is
> > >   task A;
> > >   task body A is
> > >   begin
> > >     Put_Line("b");
> > >     Put_Line("b");
> > >   end A;
> > > begin
> > >   Put_Line("a");
> > >   Put_Line("a");
> > > end Task_Demo;
> > > ---------------
> >
> > The above example is erroneous, which means that the output is totally
> > unpredictable.  The reason it's erroneous is that two tasks are messing
> > with the same shared variable (the standard output file) at the same
> > time.
> 
> Bob-
> 
> Are you sure this is erroneous?

No...

You're trying to language-lawyer me to death, Ben.  ;-)

I *think* it's erroneous, and I'm sure it was *intended* to be erroneous
by the language designers.

>...The "shared variable" is hidden in the
> private part or body of a predefined library package and ARM paragraph A(3)
> says that in such cases it is the responsibility of the implementation to
> protect the shared variable from getting trashed (*).  Now Put_Line is
> equivalent to looping over Put() and then doing a New_Line so the user may
> see interspersed output -- e.g., either or both "b"s might not be
> immediately followed by a newline -- but the implementation would be
> nonconformant with the ARM if, for example, simultaneous calls on Put caused
> the machine to reboot (which was the effect one saw in an early version of
> the old Alsys DOS Ada compiler :-)

But the AARM annotation attached to this paragraph says:

    3.a   Ramification: For example, simultaneous calls to Text_IO.Put will
          work properly, so long as they are going to two different files. On
          the other hand, simultaneous output to the same file constitutes
          erroneous use of shared variables.

which indicates the intent pretty clearly.  The program above is doing
output to the same file simultaneously.

If you want RM exegesis, I'll point you to A.10.6(2), which says the
above is equivalent to passing the current output file as a parameter,
which is clearly a shared variable.

> I'm not recommending that anyone actually write code such as Task_Demo, but
> I don't think it's an example of erroneous execution.
> 
> (*) The rule actually says "The implementation shall ensure that each
> language defined subprogram is reentrant in the sense that concurrent calls
> on the same subprogram perform as specified, so long as all parameters that
> could be passed by reference denote nonoverlapping objects."  But I believe
> the intent is as I indicated.
> 
> -Ben

P.S. *You* wrote much of Annex A!

Re: Erroneous execution? (was Re: gnat: time-slicing)

[Ben Brosgol]

> > > > with Ada.Text_IO; use Ada.Text_IO;
> > > >
> > > > procedure Task_Demo is
> > > >   task A;
> > > >   task body A is
> > > >   begin
> > > >     Put_Line("b");
> > > >     Put_Line("b");
> > > >   end A;
> > > > begin
> > > >   Put_Line("a");
> > > >   Put_Line("a");
> > > > end Task_Demo;
> > > > ---------------
> > >
> > > The above example is erroneous, which means that the output is totally
> > > unpredictable.  The reason it's erroneous is that two tasks are
messing
> > > with the same shared variable (the standard output file) at the same
> > > time.
> >
> > Bob-
> >
> > Are you sure this is erroneous?
>
> No...
>
> You're trying to language-lawyer me to death, Ben.  ;-)

Not quite that extreme, but at least to the point of moderate pain and
suffering :-)

> I *think* it's erroneous, and I'm sure it was *intended* to be erroneous
> by the language designers.

I'm not so sure that it was intended to be erroneous.  If each task were
invoking Put_Line(Some_File, ...) on the same explicitly-passed file
parameter, then yes I agree that the execution would be erroneous.  But
where the shared variable is hidden (i.e., not passed as a parameter), I
believe that the implementation needs to provide the protection (for
subprograms from predefined packages).

As an example of this principle, suppose that the implementor of
Ada.Numerics.Elementary_Functions decided to keep a hash table of (arg,
sin(arg)) pairs in the package body; i.e., sin(arg) does a hash table lookup
and possible insertion.  There's no way that the user would know this, so if
the implementation did not protect the shared hash table from simultaneous
access, calling sin(x) from concurrent tasks could result in erroneous
execution.  So A(3) kicks in and requires the protection to be supplied.  I
think the same principle applies to the Put(Char), although in this case it
may be a bit more obvious that there's a shared variable lurking in the
shadows.

> >...The "shared variable" is hidden in the
> > private part or body of a predefined library package and ARM paragraph
A(3)
> > says that in such cases it is the responsibility of the implementation
to
> > protect the shared variable from getting trashed (*).  Now Put_Line is
> > equivalent to looping over Put() and then doing a New_Line so the user
may
> > see interspersed output -- e.g., either or both "b"s might not be
> > immediately followed by a newline -- but the implementation would be
> > nonconformant with the ARM if, for example, simultaneous calls on Put
caused
> > the machine to reboot (which was the effect one saw in an early version
of
> > the old Alsys DOS Ada compiler :-)
>
> But the AARM annotation attached to this paragraph says:
>
>     3.a   Ramification: For example, simultaneous calls to Text_IO.Put
will
>           work properly, so long as they are going to two different files.
On
>           the other hand, simultaneous output to the same file constitutes
>           erroneous use of shared variables.

Well of course the AARM has no formal status :-)  Also, the wording in 3.a
is ambiguous, since it might be referring to the Put procedure that has a
File_Type as an explicit parameter, in which case I agree that the
simultaneous calls are erroneous.

> which indicates the intent pretty clearly.

Or maybe not so clearly :-)

> The program above is doing
> output to the same file simultaneously.

Agreed, but I still think there's a difference (in the obligation of the
implementation to protect against simultaneous access) based on whether the
file is passed as an explicit parameter or is hidden in the implementation.

> If you want RM exegesis, I'll point you to A.10.6(2), which says the
> above is equivalent to passing the current output file as a parameter,
> which is clearly a shared variable.

A.10.6.2 says: "All procedures Get and Put have forms with a file parameter,
written first. Where this parameter is omitted, the appropriate (input or
output) current default file is understood to be specified."  This is not
quite the same as saying that the current default file is understood to be
passed as a parameter.  I.e., "specified" could be interpreted as "the file
that is operated upon by the procedure".

> > I'm not recommending that anyone actually write code such as Task_Demo,
but
> > I don't think it's an example of erroneous execution.
> >
> > (*) The rule actually says "The implementation shall ensure that each
> > language defined subprogram is reentrant in the sense that concurrent
calls
> > on the same subprogram perform as specified, so long as all parameters
that
> > could be passed by reference denote nonoverlapping objects."  But I
believe
> > the intent is as I indicated.
> >
> > -Ben
>
> P.S. *You* wrote much of Annex A!

True, which is why I raised this issue in the first place :-) although if
you do not have a similar recollection then maybe what I am remembering (the
non-erroneousness of simultaneous calls on Put(Char)) is an intermediate
decision that was later changed?  In any event I will not claim the credit /
blame for the wording of A(3); that was from the pen of Chairman Tuck.

-Ben

Re: Erroneous execution? (was Re: gnat: time-slicing)

[Robert A Duff]

"Ben Brosgol" <brosgol@world.std.com> writes:

> > You're trying to language-lawyer me to death, Ben.  ;-)
> 
> Not quite that extreme, but at least to the point of moderate pain and
> suffering :-)

;-)

> > I *think* it's erroneous, and I'm sure it was *intended* to be erroneous
> > by the language designers.
> 
> I'm not so sure that it was intended to be erroneous.  If each task were
> invoking Put_Line(Some_File, ...) on the same explicitly-passed file
> parameter, then yes I agree that the execution would be erroneous.  But
> where the shared variable is hidden (i.e., not passed as a parameter), I
> believe that the implementation needs to provide the protection (for
> subprograms from predefined packages).

It seems to me that Put_Line(X) ought to have *exactly* the same
semantics as Put_Line(Current_Output, X).  So if one is erroneous (when
executed simultaneously by two different tasks) then so should the
other.

I must admit that the RM wording is not crystal clear on this point.

Besides, if it's not erroneous, I see no particular reason why the
required locking would be at the character level.  Why not at the level
of individual calls like Put_Line?  Why can two simultaneous Put_Lines
intersperse the characters, but not the bits?  Why shouldn't they be
required to intersperse lines?

> As an example of this principle, suppose that the implementor of
> Ada.Numerics.Elementary_Functions decided to keep a hash table of (arg,
> sin(arg)) pairs in the package body; i.e., sin(arg) does a hash table lookup
> and possible insertion.  There's no way that the user would know this, so if
> the implementation did not protect the shared hash table from simultaneous
> access, calling sin(x) from concurrent tasks could result in erroneous
> execution.  So A(3) kicks in and requires the protection to be supplied.  I
> think the same principle applies to the Put(Char), although in this case it
> may be a bit more obvious that there's a shared variable lurking in the
> shadows.

The sin(x) example seems different.  Surely two simultaneous calls to
sin should be OK, since sin is a mathematical function.  If it has
internal (implementation-level) side-effects, then the implementation
should hide them.  But Put_Line is different -- it is *supposed* to have
a side effect, namely, it is supposed to write upon the Current_Output
file.  (In fact, it seems silly to call that a "side effect"; it's
really just the "effect" (no "side" about it).)

> Well of course the AARM has no formal status :-)

True (and I see the smiley).  But the AARM indicates (often more clearly
than the RM) what the language designers intended.  Language lawyers who
ignore the AARM do so at their peril.

>...Also, the wording in 3.a
> is ambiguous, since it might be referring to the Put procedure that has a
> File_Type as an explicit parameter, in which case I agree that the
> simultaneous calls are erroneous.
> 
> > which indicates the intent pretty clearly.
> 
> Or maybe not so clearly :-)

OK, I admit it's not clear.

> > P.S. *You* wrote much of Annex A!
> 
> True, which is why I raised this issue in the first place :-) although if
> you do not have a similar recollection then maybe what I am remembering (the
> non-erroneousness of simultaneous calls on Put(Char)) is an intermediate
> decision that was later changed?  In any event I will not claim the credit /
> blame for the wording of A(3); that was from the pen of Chairman Tuck.

Yeah, and I think *I* wrote A(3.a).  I could be misremembering that,
though.  I think I meant all the Put procedures when I said "Put".

- Bob

Re: Erroneous execution? (was Re: gnat: time-slicing)

[Robert Dewar]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcck7name3h.fsf@shell01.TheWorld.com>...
> > Bob-
> > 
> > Are you sure this is erroneous?
> 
> No...

Yes, of course it's erroneous. I think you meant to say
"are you sure that the RM precisely says that it is
erroneous". That's a different question, whose answer
is not particularly interesting :-)

> >  But I believe
> > the intent is as I indicated.

No, the intent is that this be erroneous, nothing else
makes sense.

Re: time-slicing

[SteveD]

"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.15.10.24.43.431977.7868@gmx.net...
[snip]
> But I want the output to be:
>
> ab
>
> ab
>

The following program gives the desired result by creating a task-safe
version of Put_Line (actually on W2K I get ba ba instead of ab ab).

There are no guarantees on how the run time system will behave with multiple
tasks sending output to the same file, but it's easy to use have multiple
task send the data to one task that exclusively accesses the file.


With Ada.Text_IO;

Procedure Task_Demo Is

  Task Safe_Io is
    Entry Put( ch : Character );
    Entry New_Line;
  end Safe_Io;

  Task Body Safe_Io is
    Out_Char : Character;
  begin
    loop
      select
        Accept Put( ch : Character ) do
          Out_Char := ch;
        end;
        Ada.Text_Io.Put( Out_Char );
      or
        Accept New_Line;
        Ada.Text_Io.New_Line;
      or
        terminate; -- quit when the main program has terminated
      end select;
    end loop;
  end Safe_Io;

  procedure Put_Line( Item : String ) is
  begin
    for index in Item'Range loop
      Safe_Io.Put( Item( index ) );
      Delay 0.0;  -- force a context switch
    end loop;
    Safe_Io.New_Line;
    Delay 0.0;
  end Put_Line;

  Task A;
  Task Body A Is
  Begin
    Put_Line("b");
    Put_Line("b");
  End A;
Begin
  Put_Line("a");
  Put_Line("a");
End Task_Demo;

> (the tutorial says that this is the output with enabled time-slicing)
>
> I have tried to use -gnatT100, and -gnatT1, and pragma
> Time_Slice(0.000001) etc., but none of this works.
> I have gnat for Linux.
>
> Jan
>

Re: time-slicing

[Jan Prazak]

On Fri, 19 Jul 2002 02:17:11 -0100, SteveD wrote:

Thanks for the example, I have seen a similar one in a book.

> The following program gives the desired result by creating a task-safe
> version of Put_Line (actually on W2K I get ba ba instead of ab ab).

That's interesting. It means that Ada for Win does start tasks in the
declarative region first, and then the main part is started.

Re: time-slicing

[SteveD]

"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.19.12.11.27.628405.1504@gmx.net...
> On Fri, 19 Jul 2002 02:17:11 -0100, SteveD wrote:
>
> Thanks for the example, I have seen a similar one in a book.
>
> > The following program gives the desired result by creating a task-safe
> > version of Put_Line (actually on W2K I get ba ba instead of ab ab).
>
> That's interesting. It means that Ada for Win does start tasks in the
> declarative region first, and then the main part is started.
>

Which is what I would expect on any platform although W2K happens to be the
only platform I tested on.

In Ada elaboration within a module is performed in the order things appear
inside the module.  Things that appear before the "begin" are elaborated
before the body of the main procedure.  It would be awkward to do otherwise
since things used by the body would not be initialized.

SteveD