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,6009c73a58f787a0
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-11 17:12:13 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-1-176.cvx1.telinco.NET!not-for-mail
From: "Nick Roberts" <nickroberts@adaos.worldonline.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: How to avoid unreferenced objects (mutexes etc)
Date: Sat, 12 Jan 2002 01:11:43 -0000
Message-ID: <a1o2h1$sfe3f$5@ID-25716.news.dfncis.de>
References: <3c3ee8c8.105408250@News.CIS.DFN.DE>
NNTP-Posting-Host: ppp-1-176.cvx1.telinco.net (212.1.136.176)
X-Trace: fu-berlin.de 1010797921 29866095 212.1.136.176 (16 [25716])
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Xref: archiver1.google.com comp.lang.ada:18807
Date: 2002-01-12T01:11:43+00:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3c3ee8c8.105408250@News.CIS.DFN.DE...

> 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 null record;

> 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;
>
> The idea is to write critical sections as follows:
>
>    Temp : Lock (Mutex_of_a_resource'Access);
> begin
>    ...  -- Safe access to the resource
> end; -- Mutex is released even if an exception propagates


This may well be simply my own taste, but I would much prefer the critical
section to be written thus:


  type Indirect_Mutex is access all Mutex;

  The_Lock: aliased Mutex;

  ...

    Lock: [constant] Indirect_Mutex := The_Lock'Access;
  begin
    -- here we can do any non-critical pre-processing
    Lock.Seize;
    begin
      -- critical code goes here
    exception
      when others =>
        -- reset resource state to something stable
    end;
    Lock.Release;
    -- here we can do any non-critical post-processing
  end;


This way, no mucking about with finalisation or unreferenced objects is
required, and you have natural places to put pre- and post-processing code.
More importantly, this scheme ensures that if some critical processing
(presumably messing about with the state of the resource) does go wrong, the
resource is 'cleaned up' before any other innocent task can try using it.

However, really, a much better design is like this:


  protected type My_Resource_Type is
    procedure Do_Something_Critical;
  private
    ... -- resource state
  end;

  ...

  protected body My_Resource_Type is

    procedure Do_Something_Critical is
    begin
      -- critical code here
    exception
      when others =>
        -- reset resource state to something stable
    end;

  end My_Resource_Type;

  ...

  The_Resource: My_Resource_Type;

  ...

  begin
    -- pre-processing
    The_Resource.Do_Something_Critical;
    -- post-processing
  end;


The general idea is that a mutex is a low-level synchronisation construct,
and Ada provides a higher-level construct (protected objects) that takes
away much of the pain and danger of using mutexes directly.

--
Best wishes,
Nick Roberts