new_line in a put_line

new_line in a put_line

[Vlad]

Hi all,

Is there a way of prepending a new_line to a put_line.
The reason I need this is that I have multiple tasks outputing to a\
single file. Some of them use Text_IO.Put rather then Text_IO.Put_Line.
And because of this, some of these outputs get written on the same line
as my outputs.

TIA

--
Vladimir Bednikov

Re: new_line in a put_line

[Preben Randhol]

Vlad wrote:
> Hi all,
> 
> Is there a way of prepending a new_line to a put_line.  The reason I
> need this is that I have multiple tasks outputing to a\ single file.
> Some of them use Text_IO.Put rather then Text_IO.Put_Line.  And
> because of this, some of these outputs get written on the same line as
> my outputs.

Either use ASCII.LF

Like

Put ("Hello Word" & ASCII.LF & "Anybody out there?" & ASCII.LF);

or

Put ("Hello Word");
New_Line;
Put ("Anybody out there?");

-- 
Preben Randhol ------------------------ http://www.pvv.org/~randhol/ --
                          �1984 is soon coming to a computer near you.�

Re: new_line in a put_line

[Dmitry A. Kazakov]

On Mon, 2 Dec 2002 16:06:58 +1030, "Vlad" <vbednikov@optusnet.com.au>
wrote:

>Is there a way of prepending a new_line to a put_line.
>The reason I need this is that I have multiple tasks outputing to a\
>single file. Some of them use Text_IO.Put rather then Text_IO.Put_Line.
>And because of this, some of these outputs get written on the same line
>as my outputs.

Concurrent access to Text_IO might be non-portable [bounded error?].
There are two better possibilities to do it:

1. Use a protected object (to implement mutex, but no I/O from
protected operations!)

2. Use a task that does all I/O (i.e. a monitor)

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

Re: new_line in a put_line

[Matthew Heaney]

"Vlad" <vbednikov@optusnet.com.au> wrote in message news:<aserlb$juh$1@fang.dsto.defence.gov.au>...
>
> Is there a way of prepending a new_line to a put_line.
> The reason I need this is that I have multiple tasks outputing to a\
> single file. Some of them use Text_IO.Put rather then Text_IO.Put_Line.
> And because of this, some of these outputs get written on the same line
> as my outputs.

If you have multiple tasks writing to the same file, then you're going
to have to synchronize access to the file through some intermediary,
as a task or protected object (the latter requires care).  Therefore,
there should already be a layer between Text_IO and the writing tasks,
which means that you can insert whatever extra code (e.g. a call to
New_Line) you deem necessary.

Re: new_line in a put_line

[Robert A Duff]

"Vlad" <vbednikov@optusnet.com.au> writes:

> Is there a way of prepending a new_line to a put_line.
> The reason I need this is that I have multiple tasks outputing to a\
> single file. Some of them use Text_IO.Put rather then Text_IO.Put_Line.
> And because of this, some of these outputs get written on the same line
> as my outputs.

You seem to be assuming that each call to Put or Put_Line is atomic.
That's not true, so inserting a new-line into the string passed to
Put_Line is not a correct solution.

If one task says:

    Put_Line("Hello");

and another task simultaneously says:

    Put_Line("Goodbye");

the program is erroneous, which means it can have totally unpredictable
behavior.  It might intersperse the characters, so you get:

    HelGoodl
    obye

or it might print what you want:

    Hello
    Goodbye

or it might crash, or anything else.

What you need to do is synchronize your accesses to the standard output
file, perhaps using a protected object.

- Bob

Re: new_line in a put_line

[Frank J. Lhota]

"Preben Randhol" <randhol+news@pvv.org> wrote in message
news:slrnaumb0a.en.randhol+news@kiuk0152.chembio.ntnu.no...
> Vlad wrote:
> Either use ASCII.LF
>
> Like
>
> Put ("Hello Word" & ASCII.LF & "Anybody out there?" & ASCII.LF);
>
> or <snip>

There is no one llne terminator used by all operating systems. The Microsoft
OS's use the character sequence (ASCII.CR, ASCII.LF) to end a line. The Mac
OS uses ASCII.CR. And VMS uses an entirely different way of indicating the
end of a text line (basically, each line has a prefix indicating the number
of characters in the line). For this reason, there is no guarantee that
writing ASCII.LF will create a new line on all platforms. The right way to
get a new line is to call New_Line.

Of course, this does not in and of itself solve the poster's original
problem, but as indicated elsewhere in this thread, the right solution is to
use a separate task or protected object for writing to the file.

Re: new_line in a put_line

[Fraser Wilson]

mheaney@on2.com (Matthew Heaney) writes:

> If you have multiple tasks writing to the same file, then you're going
> to have to synchronize access to the file through some intermediary,
> as a task or protected object (the latter requires care).

I've seen a couple of mentions of problems using protected objects for
atomic file output.  What's the specific issue?  I.e., why isn't this
sufficient?

   protected File_Operation is
      procedure Put_Line (Text : String);
   end File_Operation;

   protected body File_Operation is
      procedure Put_Line (Text : String) is
      begin
         Ada.Text_IO.Put_Line (Text);
      end Put_Line;
   end File_Operation;

Oh, wait on, is it something to do with 9.5.1(8)?

Fraser.

Re: new_line in a put_line

[Grein, Christoph]

> I've seen a couple of mentions of problems using protected objects for
> atomic file output.  What's the specific issue?  I.e., why isn't this
> sufficient?
> 
>    protected File_Operation is
>       procedure Put_Line (Text : String);
>    end File_Operation;
> 
>    protected body File_Operation is
>       procedure Put_Line (Text : String) is
>       begin
>          Ada.Text_IO.Put_Line (Text);
>       end Put_Line;
>    end File_Operation;
> 
> Oh, wait on, is it something to do with 9.5.1(8)?

You've spotted it. Also 9.5.1(18).

> Fraser.

Re: new_line in a put_line

[Dmitry A. Kazakov]

On 03 Dec 2002 12:33:37 +0100, Fraser Wilson
<newsfraser@blancolioni.org> wrote:

>mheaney@on2.com (Matthew Heaney) writes:
>
>> If you have multiple tasks writing to the same file, then you're going
>> to have to synchronize access to the file through some intermediary,
>> as a task or protected object (the latter requires care).
>
>I've seen a couple of mentions of problems using protected objects for
>atomic file output.  What's the specific issue?  I.e., why isn't this
>sufficient?

Just do not do I/O from them. Define a mutex as a protected object and
a spin lock as a controlled type (less troubles with releasing a
mutex):

with Ada.Finalization;
package Sync is
   protected type Mutex is
      entry Seize;
      procedure Release;
   private
      Owned : Boolean := False;
   end Mutex;
   type Lock (Resource : access Mutex) is new
      Ada.Finalization.Limited_Controlled with private;      
private
   type Lock (Resource : access Mutex) is new
      Ada.Finalization.Limited_Controlled with null record;
   procedure Initialize (Object : in out Lock);
   procedure Finalize (Object : in out Lock);
end Sync;
---------------------------------------
package body Sync is
   protected body Mutex is   
      entry Seize when not Owned is
      begin
         Owned := True;
      end Seize;
      procedure Release is
      begin
         Owned := False;
      end Release; 
   end Mutex;
   procedure Initialize (Object : in out Lock) is
   begin
      Object.Resource.Seize;
   end Initialize;
   procedure Finalize (Object : in out Lock) is
   begin
      Object.Resource.Release;
   end Finalize;
end Sync;
---------------------------------------
Now your task-safe I/O package could be very sraightforward:

package File_Operation is
   procedure Put_Line (Text : String);
end File_Operation;
--------------------------------------------------------
with Ada.Text_IO;
with Sync; use Sync;
package body File_Operation is
   Write_Mutex : aliased Mutex;
   procedure Put_Line (Text : String) is
      Get_It : Lock (Write_Mutex'Access);
   begin
      Ada.Text_IO.Put_Line (Text);
   end Put_Line;
end File_Operation;

>Oh, wait on, is it something to do with 9.5.1(8)?

There could be an implementation of protected objects that would use
one lock for all of them. Now imagine, that you do I/O from a
protected operation, so no other protected operation can start on any
other object until I/O completion. That would be sort of MS Windows!
(:-))

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

Re: new_line in a put_line

[Fraser Wilson]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> Just do not do I/O from them. Define a mutex as a protected object and
> a spin lock as a controlled type (less troubles with releasing a
> mutex):

[..]

>    procedure Put_Line (Text : String) is
>       Get_It : Lock (Write_Mutex'Access);
>    begin
>       Ada.Text_IO.Put_Line (Text);
>    end Put_Line;

Something inside me rebels at using side-effects from a declaration
like that.  I can't really talk; my database library unlocks objects
as they go out of scope, but ... well, I know that code gets executed
in declarations, but I don't necessarily want to be this aware of it.

On the other hand, it's just a monitor, I shouldn't be so scared :)

cheers,
Fraser.

Re: new_line in a put_line

[Fraser Wilson]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> You've spotted it. Also 9.5.1(18).

That'll teach me to scan too quickly.  Thanks!

For those of you without the RM handy, performing potentially blocking
actions is a bounded error, and I/O is potentially blocking (duh!)

Fraser.

Re: new_line in a put_line

[Grein, Christoph]

> >    procedure Put_Line (Text : String) is
> >       Get_It : Lock (Write_Mutex'Access);
> >    begin
> >       Ada.Text_IO.Put_Line (Text);
> >    end Put_Line;
> 
> Something inside me rebels at using side-effects from a declaration
> like that.  I can't really talk; my database library unlocks objects
> as they go out of scope, but ... well, I know that code gets executed
> in declarations, but I don't necessarily want to be this aware of it.
> 
> On the other hand, it's just a monitor, I shouldn't be so scared :)

This is exactly the kind of use limited controlled types are destined for.
There is a paragraph in the AARM stating that such a (seemingly unused) object 
(Get_It) must not be optimized away.

For unlimited controlled types, this does not hold, i.e. they may be optimized 
away.

Re: new_line in a put_line

[Dmitry A. Kazakov]

On 04 Dec 2002 10:31:15 +0100, Fraser Wilson
<newsfraser@blancolioni.org> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> Just do not do I/O from them. Define a mutex as a protected object and
>> a spin lock as a controlled type (less troubles with releasing a
>> mutex):
>
>[..]
>
>>    procedure Put_Line (Text : String) is
>>       Get_It : Lock (Write_Mutex'Access);
>>    begin
>>       Ada.Text_IO.Put_Line (Text);
>>    end Put_Line;
>
>Something inside me rebels at using side-effects from a declaration
>like that. 

Right, right. It is also my opinion [there was a thread regarding this
subject in c.l.a] that using unused (:-)) objects probably indicates a
design problem. A task-based design might be better.

> I can't really talk; my database library unlocks objects
>as they go out of scope, but ... well, I know that code gets executed
>in declarations, but I don't necessarily want to be this aware of it.
>
>On the other hand, it's just a monitor, I shouldn't be so scared :)

You might also pack seizing the mutex into a "proxy" object
(File_Channel):

   type File_Channel is limited private;
   procedure Put (File : in out File_Channel; Text : String);
   procedure Put_Line (File : in out File_Channel; Text : String);
   procedure New_Line (File : in out File_Channel; Text : String);
...
private
   type File_Channel is
      new Ada.Finalization.Limited_Controlled with null record;
   procedure Initialize (File : in out File_Channel);
   procedure Finalize (File : in out File_Channel);

Initialize would seize the mutex, Finalize would release it. Thus only
one instance of File_Channel may exist at a time.

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

Re: new_line in a put_line

[Robert A Duff]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 04 Dec 2002 10:31:15 +0100, Fraser Wilson
> <newsfraser@blancolioni.org> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> Just do not do I/O from them. Define a mutex as a protected object and
> >> a spin lock as a controlled type (less troubles with releasing a
> >> mutex):
> >
> >[..]
> >
> >>    procedure Put_Line (Text : String) is
> >>       Get_It : Lock (Write_Mutex'Access);
> >>    begin
> >>       Ada.Text_IO.Put_Line (Text);
> >>    end Put_Line;
> >
> >Something inside me rebels at using side-effects from a declaration
> >like that. 
> 
> Right, right. It is also my opinion [there was a thread regarding this
> subject in c.l.a] that using unused (:-)) objects probably indicates a
> design problem. A task-based design might be better.

There is nothing wrong with declaring a limited controlled object that
is used only for its Initialize/Finalize effects.  It's a common idiom
in Ada (and also in C++).

It's the *only* way in Ada to safely ensure that resources get cleaned
up -- so telling people not to use it is bad advice, IMHO.

You could reasonably argue that Ada ought to have a better syntax for
this -- one that does not involve creating dummy types.  In fact, such a
syntax was proposed as part of Ada 9X, but was rejected on the grounds
that limited controlled types provide all the necessary functionality.

A task-based design would work just fine, too.

- Bob

Re: new_line in a put_line

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 04 Dec 2002 10:31:15 +0100, Fraser Wilson
> <newsfraser@blancolioni.org> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> Just do not do I/O from them. Define a mutex as a protected object and
> >> a spin lock as a controlled type (less troubles with releasing a
> >> mutex):
> >
> >[..]
> >
> >>    procedure Put_Line (Text : String) is
> >>       Get_It : Lock (Write_Mutex'Access);
> >>    begin
> >>       Ada.Text_IO.Put_Line (Text);
> >>    end Put_Line;
> >
> >Something inside me rebels at using side-effects from a declaration
> >like that. 
> 
> Right, right. It is also my opinion [there was a thread regarding this
> subject in c.l.a] that using unused (:-)) objects probably indicates a
> design problem. 

That's what pragma Unreferenced (in GNAT) is for; it documents that
the object is declared only for the hidden effects of Initialize and
Finalize.

Assuming Lock is a controlled type, that releases the lock in
Finalize, this is an excellent design.

-- 
-- Stephe

Re: new_line in a put_line

[Dmitry A. Kazakov]

On Wed, 4 Dec 2002 15:23:14 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 04 Dec 2002 10:31:15 +0100, Fraser Wilson
>> <newsfraser@blancolioni.org> wrote:
>> 
>> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>> >
>> >> Just do not do I/O from them. Define a mutex as a protected object and
>> >> a spin lock as a controlled type (less troubles with releasing a
>> >> mutex):
>> >
>> >[..]
>> >
>> >>    procedure Put_Line (Text : String) is
>> >>       Get_It : Lock (Write_Mutex'Access);
>> >>    begin
>> >>       Ada.Text_IO.Put_Line (Text);
>> >>    end Put_Line;
>> >
>> >Something inside me rebels at using side-effects from a declaration
>> >like that. 
>> 
>> Right, right. It is also my opinion [there was a thread regarding this
>> subject in c.l.a] that using unused (:-)) objects probably indicates a
>> design problem. A task-based design might be better.
>
>There is nothing wrong with declaring a limited controlled object that
>is used only for its Initialize/Finalize effects.  It's a common idiom
>in Ada (and also in C++).

Right, it works and it is safe, but still to my taste it is a bad
design because of using exclusively side-effects.

>It's the *only* way in Ada to safely ensure that resources get cleaned
>up -- so telling people not to use it is bad advice, IMHO.

You mean controlled objects? Yes, I didn't argue against them. It is
only that I do not like "pure" lock-objects [like Lock above],
something tells me that there should be a better way. For instance, to
fuse lock with a proxy object as in my example.

>You could reasonably argue that Ada ought to have a better syntax for
>this -- one that does not involve creating dummy types.  In fact, such a
>syntax was proposed as part of Ada 9X, but was rejected on the grounds
>that limited controlled types provide all the necessary functionality.

No that was a right decision, because it would change nothing, it
would remain just a dressed side effect.

The problem as I see it, is of course that one tries to express a
CRITICAL SECTION in terms of OBJECTS. This *cannot* be good. The first
is about execution flow control the second is about data. Only OO
fundamentalists believe that objects is everything that one might
wish. (:-))

>A task-based design would work just fine, too.

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

Re: new_line in a put_line

[Jeffrey Carter]

Stephen Leake wrote:
> 
> Assuming Lock is a controlled type, that releases the lock in
> Finalize, this [using a semaphore] is an excellent design.

I would disagree. Using a high-level feature such as a protected type to 
implement a low-level construct such as a semaphore is abstraction 
inversion. Ada has high-level concurrency features, and it should be 
possible to solve this problem directly in terms of those features. 
Using a semaphore probably indicates a lack of familiarity with those 
features rather than a reasoned decision that a semaphore is the best 
solution.

For a real-time system I designed a debug-output system based on a 
protected bounded queue of bounded strings with a very high ceiling 
priority (any task could make a debug-output call) and a task with a 
very low priority (it only ran when nothing else was running) to 
actually do the output. Some logic deleted the oldest message in the 
queue if new messages were added when the queue was full, though that 
never happened in practice. The idea was that calls to produce output 
never blocked the caller so the system had minimal impact on the timing 
of the system.

Of course, that had more complex requirements than what is being 
discussed here. Apparently the OP doesn't mind if the tasks are blocked 
during output, so simply rendezvousing with a task that does the output 
would solve the problem and be simpler and clearer than the semaphore + 
protected type approach.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: new_line in a put_line

[Stephen Leake]

Jeffrey Carter <jrcarter@acm.org> writes:

> Stephen Leake wrote:
> > Assuming Lock is a controlled type, that releases the lock in
> > Finalize, this [using a semaphore] is an excellent design.
> 
> I would disagree. Using a high-level feature such as a protected type
> to implement a low-level construct such as a semaphore is abstraction
> inversion. 

I said nothing about a "protected" type; I was talking about a
"controlled" type.

-- 
-- Stephe

Re: new_line in a put_line

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Stephen Leake wrote:
>> Assuming Lock is a controlled type, that releases the lock in
>> Finalize, this [using a semaphore] is an excellent design.
> 
...
> Of course, that had more complex requirements than what is being 
> discussed here. Apparently the OP doesn't mind if the tasks are blocked 
> during output, so simply rendezvousing with a task that does the output 
> would solve the problem and be simpler and clearer than the semaphore + 
> protected type approach.

The Rendezvous has the benefit that the request to perform output
is queued. This results in greater efficiency on most platforms
because it avoids having threads wake up and test to see if they
won out on the condition variable set (protected object).

It also guarantees "order". With the protected object approach a
"Johnnie come lately" task could gain access while already blocked
tasks are waiting to gain access -- destroying the waiting line
sequence. This may create some confusing to read "output".

However, the mutex does have one advantage in this scenario. If you
have to perform multiple calls to Text_IO then it makes more sense
to lock, perform I/O and then unlock. For example:

Lock;
New_Line;
Put_line("Hello World");
Unlock;

You could implement Lock and Unlock using the Rendevous however.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
Need to clean up your PATH or LD_LIBRARY_PATH? Try unique_path at
http://home.cogeco.ca/~ve3wwg/unique_path (awk script)

Re: new_line in a put_line

[tmoran]

> The problem as I see it, is of course that one tries to express a
> CRITICAL SECTION in terms of OBJECTS. This *cannot* be good. The first
> is about execution flow control the second is about data.
  Then you should use a task.  Using the lock object is a short, possibly
faster, idiom to accomplish the purpose.  It's like the "good morning" in
"Good morning gentlemen.  I have some bad news..."  You are not trying to
say the morning is a good one, you are trying to say "ok, let's get
started, I have the floor and want your attention." "Good morning" is
quicker.
  It may require some comments to explain what's going on to someone
unfamiliar with the idiom, but it's a valuable idiom.  A recent thread
here mentioned using an asm string scan operation in conjunction with
boolean arrays.  A purist might say that's not what it was intended for,
but a pragmatist would say it's an excellent idea.

Re: new_line in a put_line

[Simon Wright]

tmoran@acm.org writes:

> > The problem as I see it, is of course that one tries to express a
> > CRITICAL SECTION in terms of OBJECTS. This *cannot* be good. The first
> > is about execution flow control the second is about data.
>   Then you should use a task.  Using the lock object is a short, possibly
> faster, idiom to accomplish the purpose.  It's like the "good morning" in
> "Good morning gentlemen.  I have some bad news..."  You are not trying to
> say the morning is a good one, you are trying to say "ok, let's get
> started, I have the floor and want your attention." "Good morning" is
> quicker.
>   It may require some comments to explain what's going on to someone
> unfamiliar with the idiom, but it's a valuable idiom.  A recent thread
> here mentioned using an asm string scan operation in conjunction with
> boolean arrays.  A purist might say that's not what it was intended for,
> but a pragmatist would say it's an excellent idea.

I suppose the tension is between an open protocol, using lock objects,
with the risk that someone forgets to use it, and a closed protocol
which ensures that people do the right thing but requires interfaces
for all the things they need to do.

Re: new_line in a put_line

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> 
> The Rendezvous has the benefit that the request to perform output
> is queued. This results in greater efficiency on most platforms
> because it avoids having threads wake up and test to see if they
> won out on the condition variable set (protected object).

I think you're mistaken. After performing a protected procedure or 
entry, it's perfectly legal for the same task to check the barriers of 
the object. I don't know about implementations, but this is certainly 
intended behavior for protected objects. Thus, tasks don't have to "wake 
up" until they are ready to run.

> 
> It also guarantees "order". With the protected object approach a
> "Johnnie come lately" task could gain access while already blocked
> tasks are waiting to gain access -- destroying the waiting line
> sequence. This may create some confusing to read "output".

If you need to guarantee order for a protected operation it should be an 
entry. This guarantees the same order as for a task entry.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers

Re: new_line in a put_line

[Grein, Christoph]

> You might also pack seizing the mutex into a "proxy" object
> (File_Channel):
> 
>    type File_Channel is limited private;
>    procedure Put (File : in out File_Channel; Text : String);
>    procedure Put_Line (File : in out File_Channel; Text : String);
>    procedure New_Line (File : in out File_Channel; Text : String);
> ...
> private
>    type File_Channel is
>       new Ada.Finalization.Limited_Controlled with null record;
>    procedure Initialize (File : in out File_Channel);
>    procedure Finalize (File : in out File_Channel);
> 
> Initialize would seize the mutex, Finalize would release it. Thus only
> one instance of File_Channel may exist at a time.

No, nothing prevents you from declaring lots of File_Channel objects concurrently, even 
arrays of them.

Re: new_line in a put_line

[Grein, Christoph]

> > >>    procedure Put_Line (Text : String) is
> > >>       Get_It : Lock (Write_Mutex'Access);
> > >>    begin
> > >>       Ada.Text_IO.Put_Line (Text);
> > >>    end Put_Line;
> > >
> > >Something inside me rebels at using side-effects from a declaration
> > >like that. 
> > 
> > Right, right. It is also my opinion [there was a thread regarding this
> > subject in c.l.a] that using unused (:-)) objects probably indicates a
> > design problem. 
> 
> That's what pragma Unreferenced (in GNAT) is for; it documents that
> the object is declared only for the hidden effects of Initialize and
> Finalize.
> 
> Assuming Lock is a controlled type, that releases the lock in
> Finalize, this is an excellent design.

This should only be necessary for objects of not limited controlled types. As I said, 
limited controlled objects must not be optimized away.

Re: new_line in a put_line

[Dmitry A. Kazakov]

On Wed, 04 Dec 2002 18:11:24 GMT, tmoran@acm.org wrote:

>> The problem as I see it, is of course that one tries to express a
>> CRITICAL SECTION in terms of OBJECTS. This *cannot* be good. The first
>> is about execution flow control the second is about data.
>  Then you should use a task.

Maybe, Ada.Streams + a hidden task or something like Jeffrey Carter
proposed.

The problem (maybe a mental one) is than one would say - what a
monster for such a simple thing! There can be two answers for that:

A. It is inherently complex
B. There should be a better solution [if we change the language]

Honestly, I do not know which answer is right.

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

Re: new_line in a put_line

[Dmitry A. Kazakov]

On Thu, 5 Dec 2002 07:16:10 +0100 (MET), "Grein, Christoph"
<christoph.grein@eurocopter.com> wrote:

>> You might also pack seizing the mutex into a "proxy" object
>> (File_Channel):
>> 
>>    type File_Channel is limited private;
>>    procedure Put (File : in out File_Channel; Text : String);
>>    procedure Put_Line (File : in out File_Channel; Text : String);
>>    procedure New_Line (File : in out File_Channel; Text : String);
>> ...
>> private
>>    type File_Channel is
>>       new Ada.Finalization.Limited_Controlled with null record;
>>    procedure Initialize (File : in out File_Channel);
>>    procedure Finalize (File : in out File_Channel);
>> 
>> Initialize would seize the mutex, Finalize would release it. Thus only
>> one instance of File_Channel may exist at a time.
>
>No, nothing prevents you from declaring lots of File_Channel objects concurrently, even 
>arrays of them.

OK, bad wording, I admit. Under "exists" I actually meant "exists at
run-time and is fully initialized".

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

Re: new_line in a put_line

[Preben Randhol]

Frank J. Lhota wrote:
> There is no one llne terminator used by all operating systems. The
> Microsoft OS's use the character sequence (ASCII.CR, ASCII.LF) to end
> a line. The Mac OS uses ASCII.CR. And VMS uses an entirely different
> way of indicating the end of a text line (basically, each line has a
> prefix indicating the number of characters in the line). For this
> reason, there is no guarantee that writing ASCII.LF will create a new
> line on all platforms. The right way to get a new line is to call
> New_Line.

It works in Linux, the rest is left for a task for the reader ;-) The
point is that if the OS is not specified I assume they use the same as I
do. :-)

> Of course, this does not in and of itself solve the poster's original
> problem, but as indicated elsewhere in this thread, the right solution
> is to use a separate task or protected object for writing to the file.

I misunderstood the original question. I assumed he used a protected
object.

-- 
Preben Randhol ------------------------ http://www.pvv.org/~randhol/ --
                          �1984 is soon coming to a computer near you.�

Re: new_line in a put_line

[Stephen Leake]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> > > >>    procedure Put_Line (Text : String) is
> > > >>       Get_It : Lock (Write_Mutex'Access);
> > > >>    begin
> > > >>       Ada.Text_IO.Put_Line (Text);
> > > >>    end Put_Line;
> > > >
> > > >Something inside me rebels at using side-effects from a declaration
> > > >like that. 
> > > 
> > > Right, right. It is also my opinion [there was a thread regarding this
> > > subject in c.l.a] that using unused (:-)) objects probably indicates a
> > > design problem. 
> > 
> > That's what pragma Unreferenced (in GNAT) is for; it documents that
> > the object is declared only for the hidden effects of Initialize and
> > Finalize.
> > 
> > Assuming Lock is a controlled type, that releases the lock in
> > Finalize, this is an excellent design.
> 
> This should only be necessary 

It's not "necessary" in any case. It does avoid a warning from GNAT,
and it informs the reader. That's what I meant by "documents".

> for objects of not limited controlled types. As I said, limited
> controlled objects must not be optimized away.

Yes, the reader could lookup the type of the variable and realized it
is limited controlled. Unreferenced is quicker and clearer.

-- 
-- Stephe

Re: new_line in a put_line

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> The Rendezvous has the benefit that the request to perform output
>> is queued. This results in greater efficiency on most platforms
>> because it avoids having threads wake up and test to see if they
>> won out on the condition variable set (protected object).
> 
> I think you're mistaken. After performing a protected procedure or 
> entry, it's perfectly legal for the same task to check the barriers of 
> the object. I don't know about implementations, but this is certainly 
> intended behavior for protected objects. Thus, tasks don't have to "wake 
> up" until they are ready to run.

When you look behind the scenes at the _implementation_, for some
platforms (for some UNIX at least), these things boil down to pthread
calls. For example:

   http://www.cs.nmsu.edu/~jcook/Tools/pthreads/pthread_cond.html says :

   int pthread_cond_signal (pthread_cond_t *cond);

   This wakes up at least one thread blocked on the condition variable.
   Remember that they must each re-acquire the mutex before they can
   return, so they will exit the block one at a time.

So if pthread_cond_signal() is used at all in the implementation of
a protected object, you will have (on many platforms) the possibility
that a number of threads awaken to see if they "won".  On some
UNIX platforms this is a serious issue when you have 500+ threads
(this is similar to the UNIX problem of 500+ processes waking up
when a semaphore gets notified -- believe it or not, on
many platforms, all processes unswap to see if they "won", leading
to serious performance problems [e.g. HPUX].)

Now whether this is better or worse than rendezvous, is open to
implementation also. I do know that for pthread supported
platforms, GNAT does use pthread_cond_signal and pthread_cond_wait,
which are open to the problems presented (see the source file
for system.task_primitives.operations.adb).  The O/S will determine
whether or not one or multiple threads awaken however (it might be that
Linux queues them for example). But if you are taking portability
into mind, you should assume that all threads awaken (only one will
stay awake of course, because only one thread can win -- like
the movie "Highlander" -- "there can only be one"). ;-)

Is the rendezvous better?  I don't know, because I didn't dig that
closely into the sources. But potentially, I would think that with
a queue being used, it could be implemented such that only the task
on the front of the queue gets "signalled" to continue (each task
would then need its own "condition variable").

>> It also guarantees "order". With the protected object approach a
>> "Johnnie come lately" task could gain access while already blocked
>> tasks are waiting to gain access -- destroying the waiting line
>> sequence. This may create some confusing to read "output".
> 
> 
> If you need to guarantee order for a protected operation it should be an 
> entry. This guarantees the same order as for a task entry.

OK then, this makes the distinction between rendezvous and protected
objects unimportant in the "ordering" context. It also probably kills
the "efficiency" debate, because I would assume that the same
implmentation would be used for both.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: new_line in a put_line

[tmoran]

> >  Then you should use a task.
> The problem (maybe a mental one) is than one would say - what a
> monster for such a simple thing!
  A second task and a rendezvous does seem a little large.  That's
why the controlled-object-critical-region idiom is often preferred.