From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a046ce7f5ee1fa51
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-12-03 07:02:00 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail
From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: new_line in a put_line
Date: Tue, 03 Dec 2002 16:01:58 +0100
Message-ID: <gjgpuu012viiefi3is2skthq7j13vg3969@4ax.com>
References: <aserlb$juh$1@fang.dsto.defence.gov.au>
 <1ec946d1.0212020657.2bd8b5c@posting.google.com>
 <u7kerbalq.fsf@FWILSON.i-did-not-set--mail-host-address--so-shoot-me>
NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: fu-berlin.de 1038927718 29053428 212.79.194.111 (16 [77047])
X-Newsreader: Forte Agent 1.8/32.548
Xref: archiver1.google.com comp.lang.ada:31386
Date: 2002-12-03T16:01:58+01:00
List-Id: <comp.lang.ada>

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