[newbie question] tasks and protected types

[newbie question] tasks and protected types

[fabio de francesco]

Hello,

It's the first time I have something to do with protected types and
tasks, so please forgive this newbie question.

The problem is that I have the following program that compiles without
errors but that must have some logical errors. When it is run, it hangs
endlessy. I have only copied the relevant part omitting what is
unneeded to this discussion, anyway it can be compiled without syntax
errors.

First please let me explain what I wanted it to do. I want two
concurrent tasks to get some numbered "tickets" at random intervals.
Each different "ticket" number must be given to each task without
duplication. Every time a task is provided with "ticket" the name of
the task itself and the number is showed. This is like a bank with two
doors assigning numbered tickets to entering customers in order to be
later served at the counter by showing tickets representing order of
arrival.

So I wanted to create two tasks (D1, D2) that wait to be activated with
"Start()". Each of them ask the protected object for a number at random
intervals and then show it with "Put()".

I am not even sure if it is the correct logical implementation. Please,
let me know what I am missing. I apologize you all if my poor English
prevented proper explanation of this issue.

Regards,

fmdf


-- manage.adb

with Ada.Text_IO, Ada.Numerics.Float_Random;
use Ada.Text_IO, Ada.Numerics.Float_Random;

procedure Manage is

    protected Tickets is
        procedure Assign(New_Value: out Positive);
    private
            Data: Integer := 0;
    end Tickets;

    protected body Tickets is
        procedure Assign(New_Value: out Positive) is
        begin
            Data := Data + 1;
            New_Value := Data;
        end Assign;
    end Tickets;

    G : Generator;

    task type Door is
        entry Start( Str : in String; Tm : in Positive );
    end Door;

    task body Door is
        Msg : String := "";
        Val : Positive;
        Times : Positive;
    begin
        accept Start( Str : in String; Tm : in Positive ) do
            Msg := Str;
            Times := Tm;
        end Start;
        for I in 1..Times loop
            delay( Duration( Random( G ) ) );
            Tickets.Assign( Val );
            Put( Msg & " counts " & Natural'Image( Val ) );
            Flush;
        end loop;
    end Door;

    D1 : Door;
    D2 : Door;

begin

    Reset( G );
    D1.Start( "Task 1", 6 );
    D2.Start( "Task 2", 6 );
    
end Manage;

Re: [newbie question] tasks and protected types

[tmoran]

1) Msg is a zero length string.  But you try to store Str in it, which
will only work if Str is also a null string.  This is one of those few
places in Ada where you really are forced to use an access type and
a "new" (unless somebody has a better idea).
2) G is a single object accessed simultaneously by two tasks.  Who
knows what unpleasantness may result.
3) Your output file is also a single object accessed simultaneously by
two tasks.  You may be lucky and have that work for a while, or you
may not be lucky.

When compiled and run with Janus Ada I get:

** Unhandled CONSTRAINT_ERROR
   Array length check failed
On Line Number 34 In MANAGE.DOOR.START
Called from line number 29 In MANAGE.DOOR
  ## Reraised On Line Number 51 In MANAGE
**** DEADLOCK DETECTED; program halted ****

Re: [newbie question] tasks and protected types

[Jacob Sparre Andersen]

Fabio de Francesco wrote:

[...]

>     G : Generator;

Global objects are a _very_ bad idea when doing tasking.  Move it into
your task type.

>     task body Door is
>         Msg : String := "";

Here you make the lenght of the string Msg 0.

>         Val : Positive;
>         Times : Positive;
>     begin
>         accept Start( Str : in String; Tm : in Positive ) do
>             Msg := Str;

And here you try to assign a string of length 6 to a string of length
0.  It will fail with a Constraint_Error, but with tasking you don't
always see the exceptions.

And then I also prefer to keep the printing to a single protected
object.

Here's a modified version of your program using the advice above (and
my pretty-printing style):

-----
with Ada.Text_IO, Ada.Numerics.Float_Random;
use Ada.Numerics.Float_Random;

procedure Manage is

   protected Printer is
      procedure Put_Line (Item : in     String);
   end Printer;

   protected body Printer is
      procedure Put_Line (Item : in     String) is
      begin
         Ada.Text_IO.Put_Line (Item => Item);
         Ada.Text_IO.Flush;
      end Put_Line;
   end Printer;

   protected Tickets is
      procedure Assign (New_Value :    out Positive);
   private
      Data: Integer := 0;
   end Tickets;

   protected body Tickets is
      procedure Assign (New_Value :    out Positive) is
      begin
         Data := Data + 1;
         New_Value := Data;
      end Assign;
   end Tickets;

   subtype Message is String (1 .. 6);

   task type Door is
      entry Start (Str : in     Message;
                   Tm  : in     Positive);
   end Door;

   task body Door is
      G     : Generator;
      Msg   : Message := "      ";
      Val   : Positive;
      Times : Positive;
   begin
      Reset (G);
      accept Start (Str : in     Message;
                    Tm  : in     Positive) do
         Msg := Str;
         Times := Tm;
      end Start;
      for I in 1..Times loop
         delay Duration (Random (G));
         Tickets.Assign (Val);
         Printer.Put_Line (Msg & " counts " & Natural'Image (Val));
      end loop;
   end Door;

   D1 : Door;
   D2 : Door;

begin
   D1.Start ("Task 1", 6);
   D2.Start ("Task 2", 6);
end Manage;
-----

Greetings,

Jacob
-- 
�It will not be forever. - It will just seem like it.� -- Death

Re: [newbie question] tasks and protected types

[Alex R. Mosteo]

Jacob Sparre Andersen wrote:

>    protected body Printer is
>       procedure Put_Line (Item : in     String) is
>       begin
>          Ada.Text_IO.Put_Line (Item => Item);
>          Ada.Text_IO.Flush;
>       end Put_Line;
>    end Printer;

Isn't this considered a blocking operation? I've read that it is not 
something to avoid in practice, but this advice can be specific for GNAT.

Just curious.

Re: tasks and protected types

[fabio de francesco]

Jacob Sparre Andersen wrote:
> Fabio de Francesco wrote:
>
> [...]
>
> >     G : Generator;
>
> Global objects are a _very_ bad idea when doing tasking.  Move it
into
> your task type.

Done.

>
> >     task body Door is
> >         Msg : String := "";
>
> Here you make the lenght of the string Msg 0.

Auch.

> >         Val : Positive;
> >         Times : Positive;
> >     begin
> >         accept Start( Str : in String; Tm : in Positive ) do
> >             Msg := Str;
>
> And here you try to assign a string of length 6 to a string of length
> 0.  It will fail with a Constraint_Error, but with tasking you don't
> always see the exceptions.
>
> And then I also prefer to keep the printing to a single protected
> object.

Why? Could lines come out intermixed? Does it mean that it is always
needed to protect every call to library functions and procedures? Do
they use global variables?

> Here's a modified version of your program using the advice above (and
> my pretty-printing style):
>
> [skip some code]
>

Why an error in using strings makes the program to behave as it was a
deadlock?

Thank you. Now the program runs without problems.

fabio de francesco

Re: [newbie question] tasks and protected types

[Jacob Sparre Andersen]

Alex R. Mosteo wrote:
> Jacob Sparre Andersen wrote:

> >    protected body Printer is
> >       procedure Put_Line (Item : in     String) is
> >       begin
> >          Ada.Text_IO.Put_Line (Item => Item);
> >          Ada.Text_IO.Flush;
> >       end Put_Line;
> >    end Printer;
> 
> Isn't this considered a blocking operation?

I think I have heard something like that too, but I have not been able
to find it written down anywhere.

> I've read that it is not something to avoid in practice, but this
> advice can be specific for GNAT.

I only tested my version with GNAT, so I can't disprove that.

If calls to Ada.Text_IO _are_ potentially blocking operations, that
means that one has to move the calls to a task.  But from a logical
point of view, using a protected object seems like the right way to do
it.

Jacob
-- 
A password should be like a toothbrush. Use it every day;
change it regularly; and DON'T share it with friends.

Re: tasks and protected types

[Jacob Sparre Andersen]

Fabio de Francesco wrote:
> Jacob Sparre Andersen wrote:
> > Fabio de Francesco wrote:

> > And then I also prefer to keep the printing to a single protected
> > object.
> 
> Why? Could lines come out intermixed? Does it mean that it is always
> needed to protect every call to library functions and procedures? Do
> they use global variables?

They modify the global variable "Ada.Text_IO.Standard_Output".

> Why an error in using strings makes the program to behave as it was
> a deadlock?

Exceptions in tasks is un(?)fortunately not something I really
understand.  I don't think that it matters that it is something with
strings.  I think putting a "raise Some_Exception;" in the accept
block would give the same result.

If you will accept a guess: An exception is raised in the first accept
call.  This means that the D1 task terminates (they do that, when you
have exceptions), but without finishing the accept block.  This leaves
Manage hanging, waiting for D1 (which is dead) to finish its accept
block.

Greetings,

Jacob
-- 
"Three can keep a secret if two of them are dead."

Re: [newbie question] tasks and protected types

[Adrien Plisson]

Jacob Sparre Andersen wrote:
> If calls to Ada.Text_IO _are_ potentially blocking operations, that
> means that one has to move the calls to a task.  

and what about putting them into an entry of a protected object ?

-- 
rien

Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Jacob Sparre Andersen]

Adrien Plisson wrote:
> Jacob Sparre Andersen wrote:

> > If calls to Ada.Text_IO _are_ potentially blocking operations,
> > that means that one has to move the calls to a task.
> 
> and what about putting them into an entry of a protected object?

I thought entries of protected objects also were "protected actions".
Unfortunately RM 9.5.1 isn't so clear on that question, that I am sure
if that is actually the case or not.

If entries on protected objects are not "protected actions", then that
is definitely a sensible solution.

I think I need an explanation of the difference between entries and
procedures of protected objects.  Any suggestion of some reading
materials?

Jacob
-- 
�USA fights for the right of the individual.�
�Yes.  Those of the individual George W. Bush.�
                                     -- with thanks to Olfax

Re: [newbie question] tasks and protected types

[Alex R. Mosteo]

Jacob Sparre Andersen wrote:
> If calls to Ada.Text_IO _are_ potentially blocking operations, that
> means that one has to move the calls to a task.  But from a logical
> point of view, using a protected object seems like the right way to do
> it.

True. In fact I was doing just the same when I was warned for the first 
time about this.

Later I think it was Mr. Dewar who pointed that Gnat Text_IO is thread 
safe, but don't mark my words.

Kind regards,

A. Mosteo.

Re: tasks and protected types

[Alex R. Mosteo]

Jacob Sparre Andersen wrote:

> If you will accept a guess: An exception is raised in the first accept
> call.  This means that the D1 task terminates (they do that, when you
> have exceptions), 

For the newbie information, they terminate if the exception is not 
managed somewhere in the task. For this reason having a top level 
exception manager in each task for reporting is a good idea.

task X is
begin
    ---
exception
    when E : others =>
       --  <your logging stuff here>
end;

> If you will accept a guess: An exception is raised in the first accept
> call.  This means that the D1 task terminates (they do that, when you
> have exceptions), but without finishing the accept block.  This leaves
> Manage hanging, waiting for D1 (which is dead) to finish its accept
> block.

I'm too guessing, but I think that when an exception happens inside an 
accept, the task gets the exception and the caller gets a Tasking_Error 
exception. Kinda like if the exception "splits" and goes to the two 
threads. Can someone confirm?

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Poul-Erik Andreasen]

Jacob Sparre Andersen wrote:
> Adrien Plisson wrote:
> 
>>Jacob Sparre Andersen wrote:
> 
> 
>>>If calls to Ada.Text_IO _are_ potentially blocking operations,
>>>that means that one has to move the calls to a task.
>>
>>and what about putting them into an entry of a protected object?
> 
> 
> I thought entries of protected objects also were "protected actions".
> Unfortunately RM 9.5.1 isn't so clear on that question, that I am sure
> if that is actually the case or not.
> 
> If entries on protected objects are not "protected actions", then that
> is definitely a sensible solution.
> 
> I think I need an explanation of the difference between entries and
> procedures of protected objects.  Any suggestion of some reading
> materials?
> 

http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/main.htm

Re: tasks and protected types

[Egil H. H�vik]

>
> > If you will accept a guess: An exception is raised in the first accept
> > call.  This means that the D1 task terminates (they do that, when you
> > have exceptions), but without finishing the accept block.  This leaves
> > Manage hanging, waiting for D1 (which is dead) to finish its accept
> > block.
>
> I'm too guessing, but I think that when an exception happens inside an
> accept, the task gets the exception and the caller gets a Tasking_Error
> exception. Kinda like if the exception "splits" and goes to the two
> threads. Can someone confirm?


RM 9.5.2(26):
...
When an exception is propagated from the handled_sequence_of_statements of
an accept_statement,
the same exception is also raised by the execution of the corresponding
entry_call statement.


Which means that D1.Start raises an exception, D2.Start is never called, and
Manage will wait for D2 to terminate
(D1 will terminate due to the unhandled exception)



~egilhh

Re: tasks and protected types

[Egil H. H�vik]

>
> RM 9.5.2(26):
> ...
> When an exception is propagated from the handled_sequence_of_statements of
> an accept_statement,
> the same exception is also raised by the execution of the corresponding
> entry_call statement.
>
>
> Which means that D1.Start raises an exception, D2.Start is never called,
and
> Manage will wait for D2 to terminate
> (D1 will terminate due to the unhandled exception)
>
>

... and as an accept_statement contains a handled_sequence_of_statements,
you can
add the exception handler in the accept statement directly, thus:

accept Start( Str : in String; Tm : in Positive) do
   Msg := Str;
   Times := Tm;
exception
   when others =>
      Ada.Text_IO.Put_Line("Exception caugth in accept statement");
end Start;


~egilhh

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Egil H. H�vik]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:m2acnhn43i.fsf_-_@hugin.crs4.it...
> Adrien Plisson wrote:
> > Jacob Sparre Andersen wrote:
>
> > > If calls to Ada.Text_IO _are_ potentially blocking operations,
> > > that means that one has to move the calls to a task.
> >

RM 9.5.1(18):
Certain language-defined subprograms are potentially blocking. In
particular, the subprograms of the language-defined input-output
packages that manipulate files (implicitly or explicitly) are potentially
blocking.


>
> I thought entries of protected objects also were "protected actions".
> Unfortunately RM 9.5.1 isn't so clear on that question, that I am sure
> if that is actually the case or not.
>

RM 9.5.3(8):
... For a call on an entry of a protected object, a new protected action
is started on the object (see 9.5.1).


~egilhh

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Björn Lundin]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]


2005-04-29 kl. 14.45 skrev Jacob Sparre Andersen:

> Adrien Plisson wrote:
>> Jacob Sparre Andersen wrote:
>
>>> If calls to Ada.Text_IO _are_ potentially blocking operations,
>>> that means that one has to move the calls to a task.
>>
>> and what about putting them into an entry of a protected object?
>


> I think I need an explanation of the difference between entries and
> procedures of protected objects.  Any suggestion of some reading
> materials?
>
  Ada As A Second Language by Norman Cohen

<http://www.amazon.com/exec/obidos/tg/detail/-/0070116075/103-0300811 
-4955053?v=glance>
Has a nice and long chapter about protected objects and tasking

As a remark to the issue of text_io being potentially blocking, I've  
developed code
that works as it should with Windows and gnat, but came to a total  
freeze of the process
when compiled with Object Ada. The freeze occured when calling text_io  
inside a protected procedure.
Replacing the protected object with another task solved it.

In the book above, the author mentions that io inside protected objects  
will either freeze the process,
or work, but with the protection disabled, or work very well? Anyway, I  
will always be carefull with
protected objects in the future.

/Björn
Björn Lundin
bnl at spray dot se

[-- Attachment #2: Type: text/enriched, Size: 1727 bytes --]



2005-04-29 kl. 14.45 skrev Jacob Sparre Andersen:


<excerpt>Adrien Plisson wrote:

<excerpt>Jacob Sparre Andersen wrote:

</excerpt>

<excerpt><excerpt>If calls to Ada.Text_IO _are_ potentially blocking
operations,

that means that one has to move the calls to a task.

</excerpt>

and what about putting them into an entry of a protected object?

</excerpt>

</excerpt>


<excerpt>I think I need an explanation of the difference between
entries and

procedures of protected objects.  Any suggestion of some reading

materials?


</excerpt><fontfamily><param>Arial</param><x-tad-bigger>
</x-tad-bigger><bold><x-tad-bigger>Ada</x-tad-bigger></bold><x-tad-bigger>
As A
</x-tad-bigger><bold><x-tad-bigger>Second</x-tad-bigger></bold><x-tad-bigger> </x-tad-bigger><bold><x-tad-bigger>Language</x-tad-bigger></bold><x-tad-bigger>
by Norman Cohen


<<http://www.amazon.com/exec/obidos/tg/detail/-/0070116075/103-0300811-4955053?v=glance>

Has a nice and long chapter about protected objects and tasking


</x-tad-bigger></fontfamily>As a remark to the issue of text_io being
potentially blocking, I've developed code

that works as it should with Windows and gnat, but came to a total
freeze of the process

when compiled with Object Ada. The freeze occured when calling text_io
inside a protected procedure.

Replacing the protected object with another task solved it.


In the book above, the author mentions that io inside protected
objects will either freeze the process, 

or work, but with the protection disabled, or work very well? Anyway,
I will always be carefull with

protected objects in the future.


/Björn

Björn Lundin

bnl at spray dot se

Re: tasks and protected types

[Robert A Duff]

"Egil H. H�vik" <egil.harald.hoevikNOSPAM@REMOVEkongsberg.com> writes:

> >
> > RM 9.5.2(26):
> > ...
> > When an exception is propagated from the handled_sequence_of_statements of
> > an accept_statement,
> > the same exception is also raised by the execution of the corresponding
> > entry_call statement.
> >
> >
> > Which means that D1.Start raises an exception, D2.Start is never called,
> and
> > Manage will wait for D2 to terminate
> > (D1 will terminate due to the unhandled exception)

That's right.

> ... and as an accept_statement contains a handled_sequence_of_statements,
> you can
> add the exception handler in the accept statement directly, thus:
> 
> accept Start( Str : in String; Tm : in Positive) do
>    Msg := Str;
>    Times := Tm;
> exception
>    when others =>
>       Ada.Text_IO.Put_Line("Exception caugth in accept statement");
> end Start;

That's not a good idea.  The exception we're talking about here is a
*bug*.  There's no way the task can recover from it.  In the original
example, if you added the above exception handler, the very next thing
the task will do is look at Times, which is an uninitialized variable!

If you want to print a message, follow it by "raise;" or something.

Unfortunately, that doesn't work at the end of a task body.
You can call the C 'exit' routine, or you 'abort' things,
or whatever, but an unhandled exception in a task body causes
it to terminate -- in most implementations, to *silently* terminate.
And then the rest of the system usually hangs.

Alternatively, you can debug this in a debugger.  Tell it to break on
all exceptions, and it will stop at the point of "Msg := Str;",
and then you can figure out what's going on.

- Bob

Re: tasks and protected types

[Jacob Sparre Andersen]

Egil H. H�vik wrote:

> Which means that D1.Start raises an exception, D2.Start is never called, and
> Manage will wait for D2 to terminate
> (D1 will terminate due to the unhandled exception)

Thanks for the analysis.

Jacob
-- 
People in cars cause accidents. Accidents in cars cause people.

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Jacob Sparre Andersen]

Egil H. H�vik wrote:
> Jacob Sparre Andersen wrote:
> > Adrien Plisson wrote:
> > > Jacob Sparre Andersen wrote:
> >
> > > > If calls to Ada.Text_IO _are_ potentially blocking operations,
> > > > that means that one has to move the calls to a task.
> 
> RM 9.5.1(18):
> Certain language-defined subprograms are potentially blocking. In
> particular, the subprograms of the language-defined input-output
> packages that manipulate files (implicitly or explicitly) are potentially
> blocking.

That was the paragraph I was looking for.  Unfortunately it wasn't in
the index under "potentially blocking operation".  Now it is (in my
printed version).

> > I thought entries of protected objects also were "protected
> > actions".  Unfortunately RM 9.5.1 isn't so clear on that question,
> > that I am sure if that is actually the case or not.
> >
> 
> RM 9.5.3(8):
> ... For a call on an entry of a protected object, a new protected action
> is started on the object (see 9.5.1).

It was exactly that sentence I was of about the meaning of.  I guess
your interpretation of it is that entries of protected objects, like
their functions and procedures, are protected actions.

Thanks.

Jacob
-- 
recursive, adj.; see recursive

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

"Egil H. H�vik" <egil.harald.hoevikNOSPAM@REMOVEkongsberg.com> wrote in
message news:d4tftf$m7i$1@kda-news.kongsberg.com...
>
> "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
> news:m2acnhn43i.fsf_-_@hugin.crs4.it...
> > Adrien Plisson wrote:
> > > Jacob Sparre Andersen wrote:
> >
> > > > If calls to Ada.Text_IO _are_ potentially blocking operations,
> > > > that means that one has to move the calls to a task.
> > >
>
> RM 9.5.1(18):
> Certain language-defined subprograms are potentially blocking. In
> particular, the subprograms of the language-defined input-output
> packages that manipulate files (implicitly or explicitly) are potentially
> blocking.

Right. We had a big fight about this rule in the ARG (some people wanting to
repeal or modify it), but ultimately it was left to stand. So it isn't
portable to call Text_IO from a protected object; it might raise
Program_Error or deadlock.

I think it actually does work in Janus/Ada and in GNAT, but (in our case at
least), we aren't making any promises that that will remain the case. And
its always bad practice to write code that will work only on a few
compilers, especially something as hard to track down as this would be.

                       Randy.

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Lionel Draghi]

Randy Brukardt a ï¿œcrit :
...
> 
> I think it actually does work in Janus/Ada and in GNAT, but (in our case at
> least), we aren't making any promises that that will remain the case. And
> its always bad practice to write code that will work only on a few
> compilers, especially something as hard to track down as this would be.

I fully agree with you, Randy, but it's quite difficult to ensure that 
no compiler dependant behavior is used in the code, because no compiler 
I am aware of is kind enough to put a warning on all compiler/platform 
dependencies.

When porting, some problems will be caught at compilation time (for 
example representation clause that do not compile with another compiler).
Some will be caught early at run time (for example elaboration order issue).
But some, like this one, may not be noticed before delivery, and will be 
really difficult to track down, as you said.

And here is the limit of Ada portability Myth.
OK, Ada is probably the most portable industrial compiled language.
OK, porting an Ada code is much faster than any other compiled language.
But the situation is not perfect. Ada is just 99.5% portable :-)

Those "inaccuracy" in the Ada semantics are possibly inevitable, 
precisely because of portability accross platform, and maybe also to 
preserve different compiler implementation options.

So, the only way I see to ensure that an general Ada code is fully 
portable is an ASIS tools that will warn about all risky code.
A kind of portability lint.

What dou you think about it?

-- 
Lionel Draghi

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[fabio de francesco]

Egil H. Høvik wrote:
> "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
> news:m2acnhn43i.fsf_-_@hugin.crs4.it...
> > Adrien Plisson wrote:
> > > Jacob Sparre Andersen wrote:
> >
> > > > If calls to Ada.Text_IO _are_ potentially blocking operations,
> > > > that means that one has to move the calls to a task.
> > >
>
> RM 9.5.1(18):
> Certain language-defined subprograms are potentially blocking. In
> particular, the subprograms of the language-defined input-output
> packages that manipulate files (implicitly or explicitly) are
potentially
> blocking.
>
>
> >
> > I thought entries of protected objects also were "protected
actions".
> > Unfortunately RM 9.5.1 isn't so clear on that question, that I am
sure
> > if that is actually the case or not.
> >
>
> RM 9.5.3(8):
> ... For a call on an entry of a protected object, a new protected
action
> is started on the object (see 9.5.1).
>
>
> ~egilhh

Thank you all for every insight on the subject. Anyway I don't yet
understand whether you mean that potentially "blocking" subprograms
should be put in a protected object or inversely they shouldn't.

In this thread I've been suggested to put the IO in a protected object.
Is it needed to do so?

What do you mean by "blocking"? I suppose you mean that OS can put that
process in a wait queue and switch to a new one, may be because the
first is waiting for some event like device IO. Is it correct?

Ciao,

fabio de francesco

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[fabio de francesco]

Lionel Draghi wrote:
>
> ...
>
> I fully agree with you, Randy, but it's quite difficult to ensure
that
> no compiler dependant behavior is used in the code, because no
compiler
> I am aware of is kind enough to put a warning on all
compiler/platform
> dependencies.
>
> ...
>

Isn't there in GCC/GNAT any options like "-pedantic" and "-ansi" in
order to reject all programs that do not strictly follow the standard?

fabio

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Jeffrey Carter]

fabio de francesco wrote:

> Isn't there in GCC/GNAT any options like "-pedantic" and "-ansi" in
> order to reject all programs that do not strictly follow the standard?

For GNAT,

-gnato -fstack-check -gnatE

make it strictly follow the standard. That won't affect what happens in 
your problem.

Blocking operations in protected operations are a bounded error. That 
means don't do it.

Doing IO to the same file from multiple tasks may cause interleaving.

So the simple solution to your problem as given is to define a subtype 
of String

subtype Task_Name is String (1 .. 6);

to use in your entry and Msg object, and have another task to do the 
output. That should solve your deadlock and be portable.

If task names need to be different lengths, then Msg could be an 
[Un]Bounded_String.

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Lionel Draghi]

fabio de francesco a ï¿œcrit :
...
> Isn't there in GCC/GNAT any options like "-pedantic" and "-ansi" in
> order to reject all programs that do not strictly follow the standard?

But non portable programs follows the standard, that's my point.
(Fortunatly, in the Ada world, not following the standard is not an option).

That's why you may write code that perfectly run with GNAT, unaware that 
it won't run that fine with another one.

-- 
Lionel

Re: Ada.Text_IO and protected objects

[Jacob Sparre Andersen]

Fabio de Francesco wrote:

> Thank you all for every insight on the subject. Anyway I don't yet
> understand whether you mean that potentially "blocking" subprograms
> should be put in a protected object or inversely they shouldn't.

"Potentially blocking" subprograms should not be called from
procedures, functions and entries of protected objects ("protected
actions").

> In this thread I've been suggested to put the IO in a protected
> object.  Is it needed to do so?

It is wrong to do so. - I apologise for the misleading advise.

IO has to be done from a task (optionally the main task), not from
inside a protected action.

I am not sure if the appropriate way of handling access to
Standard_Output is by using a protected object to manage a queue for
transferring data to the task doing the actual writing to
Standard_Output, or if the interaction should be through a direct
rendezvous with the task doing the actual writing to Standard_Output.

There is a "dining philosophers" example available somewhere on the
web (written by Feldman, I think), where you probably can find a good
example of how to solve the combination of tasking and IO.

> What do you mean by "blocking"? I suppose you mean that OS can put
> that process in a wait queue and switch to a new one, may be because
> the first is waiting for some event like device IO. Is it correct?

I think that is correct, but hopefully somebody more experienced in
tasking will answer the question.

Ciao,

Jacob
-- 
"If you think Tuck has said something that is completely
 wrong, you are almost certainly missing something :-)"

Re: Ada.Text_IO and protected objects

[Dmitry A. Kazakov]

On 30 Apr 2005 11:07:54 +0200, Jacob Sparre Andersen wrote:

> I am not sure if the appropriate way of handling access to
> Standard_Output is by using a protected object to manage a queue for
> transferring data to the task doing the actual writing to
> Standard_Output, or if the interaction should be through a direct
> rendezvous with the task doing the actual writing to Standard_Output.

#3: It can be also done on the context of the same task using a protected
object implementing a mutex. A controlled object is then used for safe
mutex access.

But a monitor task (the second variant you mention) is cleaner and safer in
my view. It might be slightly slower than mutexes, though that should
depend on the compiler-platform.

> There is a "dining philosophers" example available somewhere on the
> web (written by Feldman, I think), where you probably can find a good
> example of how to solve the combination of tasking and IO.

Dining philosophers is rather an example of why mutexes/semaphores are
dangerous (deadlock) and low-level and what could be done about that.

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

Re: tasks and protected types

[Simon Wright]

"Egil H. H�vik" <egil.harald.hoevikNOSPAM@REMOVEkongsberg.com> writes:

> RM 9.5.2(26): ...  When an exception is propagated from the
> handled_sequence_of_statements of an accept_statement, the same
> exception is also raised by the execution of the corresponding
> entry_call statement.

This can lead to much puzzlement if you see the traceback in the
caller!

Re: Ada.Text_IO and protected objects

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>> RM 9.5.1(18):
>> Certain language-defined subprograms are potentially blocking. In
>> particular, the subprograms of the language-defined input-output
>> packages that manipulate files (implicitly or explicitly) are potentially
>> blocking.
>
> I think it actually does work in Janus/Ada and in GNAT, 

It "works" in GNAT on Windows, but not GNAT on Lynx; you get
Program_Error or deadlock on Lynx.

Which makes sense; Windows is for playing around, Lynx is for hard
real time :).

-- 
-- Stephe

Re: Ada.Text_IO and protected objects (Was: [newbie question] tasks and protected types)

[Jean-Pierre Rosen]

Lionel Draghi a ï¿œcrit :
[snip discussion about potentially blocking operations]
> So, the only way I see to ensure that an general Ada code is fully 
> portable is an ASIS tools that will warn about all risky code.
> A kind of portability lint.
> 
> What dou you think about it?
> 
That could be a job for AdaControl, I've put it on my list of to-do rules.

Of course, if someone is *really* interested and has some funding 
available, it will raise its priority :-)

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Text_IO and protected objects

[fabio de francesco]

Dmitry A. Kazakov wrote:
> On 30 Apr 2005 11:07:54 +0200, Jacob Sparre Andersen wrote:
>
> > I am not sure if the appropriate way of handling access to
> > Standard_Output is by using a protected object to manage a queue
for
> > transferring data to the task doing the actual writing to
> > Standard_Output, or if the interaction should be through a direct
> > rendezvous with the task doing the actual writing to
Standard_Output.
>
> #3: It can be also done on the context of the same task using a
protected
> object implementing a mutex. A controlled object is then used for
safe
> mutex access.
>
> But a monitor task (the second variant you mention) is cleaner and
safer in
> my view. It might be slightly slower than mutexes, though that should
> depend on the compiler-platform.

Thank all of you. I have thought a while about the need to start a
third task to do the actual writing to Standard_Output as the second
variant mentions. I decided not to do it because the original problem
is to manage two different printer devices or output files, one at each
door. Otherwise there wouldn't be any need two have two different tasks
to emit tickets, only one would suffice. (I hope I am not missing
something...)

Anyway just to reason on the solution Dmitry and Jacob suggest, how
would you implement that one? If I have understood there would be the
need for a third task in charge to handle IO. I suppose it means that
the other two tasks have to emit "tickets" to a protected queue that
would be later read by the third task in order to print them. Is it
what you mean? How can we assure that all elements in queue are ordered
by increasing numbers if any of the previous two tasks add tickets to
this queue at random times? I think there must be something I didn't
catch. I am not even sure you were proposing a queue working in terms I
explained here. Can you make your solution clearer for me, please?

Regards,

fabio de francesco

>
> > There is a "dining philosophers" example available somewhere on the
> > web (written by Feldman, I think), where you probably can find a
good
> > example of how to solve the combination of tasking and IO.
>
> Dining philosophers is rather an example of why mutexes/semaphores
are
> dangerous (deadlock) and low-level and what could be done about that.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: Ada.Text_IO and protected objects

[Jacob Sparre Andersen]

Fabio de Francesco wrote:

> Thank all of you. I have thought a while about the need to start a
> third task to do the actual writing to Standard_Output as the second
> variant mentions. I decided not to do it because the original
> problem is to manage two different printer devices or output files,
> one at each door.

If you write to two _different_ files in the two different tasks, then
you're safe, but that was not what you were doing.

> Otherwise there wouldn't be any need two have two different tasks to
> emit tickets, only one would suffice. (I hope I am not missing
> something...)

What the two tasks in youre examle are doing, is: logging that the
protected object issues tickets to them - to a _common_ log.

> Anyway just to reason on the solution Dmitry and Jacob suggest, how
> would you implement that one? If I have understood there would be
> the need for a third task in charge to handle IO. I suppose it means
> that the other two tasks have to emit "tickets" to a protected queue
> that would be later read by the third task in order to print
> them. Is it what you mean? How can we assure that all elements in
> queue are ordered by increasing numbers if any of the previous two
> tasks add tickets to this queue at random times? I think there must
> be something I didn't catch. I am not even sure you were proposing a
> queue working in terms I explained here. Can you make your solution
> clearer for me, please?

Your original specification (if one can say there was any) didn't say
anything about having to log the issued tickets in sequence.  Please
give us a more exact description of what you want to do, before we
start making speculative experiments based on more or less wild
guesses.

Jacob
-- 
"War does not determine who is right - only who is left."
                                         -- Bertrand Russell

Re: Ada.Text_IO and protected objects

[fabio de francesco]

Jacob Sparre Andersen wrote:
> Fabio de Francesco wrote:
>
> > Thank all of you. I have thought a while about the need to start a
> > third task to do the actual writing to Standard_Output as the
second
> > variant mentions. I decided not to do it because the original
> > problem is to manage two different printer devices or output files,
> > one at each door.
>
> If you write to two _different_ files in the two different tasks,
then
> you're safe, but that was not what you were doing.

Yes, indeed.

>
> > Otherwise there wouldn't be any need two have two different tasks
to
> > emit tickets, only one would suffice. (I hope I am not missing
> > something...)
>
> What the two tasks in youre examle are doing, is: logging that the
> protected object issues tickets to them - to a _common_ log.

You're correct: to a common log. That was only a test to acquaint
myself with tasks and protected types. My attention was to the
protected object behaviour and to the general structure of a program
with tasks.

Initially the program was raising contrained errors and many of you
helped to find the bugs in it. Those errors weren't related at all to
output, in fact now it works for doing what it has been designed.

At first I wasn't particularly interested to the output, that is it
doesn't mattered to get output lines ordered by increasing "ticket"
numbers. I was only interested at solving the immediate issue that
couldn't make the program run.

Only after someone explained that output could get out interleaved I
became to investigate this other issue. So in my latest post I asked
how you would do if it were needed that lines didn't get interleaved
when going to the same output channel. Just to know how to do it when
it is required.

> > Anyway just to reason on the solution Dmitry and Jacob suggest, how
> > would you implement that one? If I have understood there would be
> > the need for a third task in charge to handle IO. I suppose it
means
> > that the other two tasks have to emit "tickets" to a protected
queue
> > that would be later read by the third task in order to print
> > them. Is it what you mean? How can we assure that all elements in
> > queue are ordered by increasing numbers if any of the previous two
> > tasks add tickets to this queue at random times? I think there must
> > be something I didn't catch. I am not even sure you were proposing
a
> > queue working in terms I explained here. Can you make your solution
> > clearer for me, please?
>
> Your original specification (if one can say there was any) didn't say
> anything about having to log the issued tickets in sequence.  Please
> give us a more exact description of what you want to do, before we
> start making speculative experiments based on more or less wild
> guesses.

Yes, indeed. I hope I've made it clearer. That's it. Sorry for my
English.

Regards,

fabio de francesco