Re: gnat: time-slicing

Re: gnat: time-slicing

[Grein, Christoph]

From: Jan Prazak <janp9@gmx.net>

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

Before arguing, please have a look at the Ada Reference Manual...

For the RM, the screen _is_ a file, named Standard_Output; and the keyboard is 
also a file, named Standard_Input. (Actually the RM does not specify what 
Standard_Output and Standard_Input stand for since this is OS dependent, it only 
says that there are these two files.)

You urgently need the RM. Go get it :-)

Re: gnat: time-slicing

[Jan Prazak]

On Thu, 18 Jul 2002 03:44:27 -0100, Grein, Christoph wrote:

> For the RM, the screen _is_ a file, named Standard_Output; and the
> keyboard is also a file, named Standard_Input. (Actually the RM does not
> specify what Standard_Output and Standard_Input stand for since this is
> OS dependent, it only says that there are these two files.)

I have downloaded "Ada distilled" (a nice tutorial) yesterday, and the
author says (in the section about Text_IO), that standard output is the
screen in most cases.

> You urgently need the RM. Go get it :-)

I have it already, but who wants to go through over 500 pages. Maybe I will
have a look, but for now I'm very busy with reading tutorials. The RM is
too detailed, so sometimes it's not easy to find an information there (it
takes time).

Re: gnat: time-slicing

[Sergey Koshcheyev]

"Jan Prazak" <janp9@gmx.net> wrote in message
news:pan.2002.07.18.17.35.54.112289.1591@gmx.net...
> On Thu, 18 Jul 2002 03:44:27 -0100, Grein, Christoph wrote:
>
> > For the RM, the screen _is_ a file, named Standard_Output; and the
> > keyboard is also a file, named Standard_Input. (Actually the RM does not
> > specify what Standard_Output and Standard_Input stand for since this is
> > OS dependent, it only says that there are these two files.)
>
> I have downloaded "Ada distilled" (a nice tutorial) yesterday, and the
> author says (in the section about Text_IO), that standard output is the
> screen in most cases.

Yes, and repeating the first sentence you yourself have quoted, "the screen
_is_ a file, named Standard_Output".

Sergey.

Re: gnat: time-slicing

[Robert A Duff]

Jan Prazak <janp9@gmx.net> writes:

> > You urgently need the RM. Go get it :-)
> 
> I have it already, but who wants to go through over 500 pages. Maybe I will
> have a look, but for now I'm very busy with reading tutorials. The RM is
> too detailed, so sometimes it's not easy to find an information there (it
> takes time).

The RM can be tough going, but if you want to know about Text_IO,
it's actually pretty readable.  Read the section on Text_IO,
and look at its definition of "file".  Actually, the issue here
is "internal file".

- Bob

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