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-12 21:45:33 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!ppp-1-17.cvx5.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: Sun, 13 Jan 2002 05:45:55 -0000
Message-ID: <a1r6tr$slh9n$1@ID-25716.news.dfncis.de>
References: <3c3ee8c8.105408250@News.CIS.DFN.DE>
 <a1o2h1$sfe3f$5@ID-25716.news.dfncis.de> <u41cg9jaqnrs56@corp.supernews.com>
NNTP-Posting-Host: ppp-1-17.cvx5.telinco.net (212.1.152.17)
X-Trace: fu-berlin.de 1010900732 30065975 212.1.152.17 (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:18844
Date: 2002-01-13T05:45:55+00:00
List-Id: <comp.lang.ada>

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u41cg9jaqnrs56@corp.supernews.com...

> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
> news:a1o2h1$sfe3f$5@ID-25716.news.dfncis.de...
> > However, really, a much better design is like this:
>
> No, because protected operations can't make blocking calls.
>
> Note that all predefined I/O packages are "potentially blocking," which
> means, for example, that you can't call Text_IO from inside a protected
> object.

Well, I had no idea that Dmitry's critical section contained blocking calls.
My comments were made on the very reasonable assumption that it didn't. I
would suggest that it is unusual for a critical section to need to make
blocking calls, and generally desirable to remove blocking calls from
critical sections wherever possible. Moreover, it is generally desirable to
reduce the execution time (both average and maximum, if possible) of a
critical section to a reasonable minimum.

> So you still need a semaphore-style type (as in the original post), to
> handle the situation in which blocking calls are made inside a critical
> section.

No you don't. If your critical section must perform a blocking action, put
it in a task. E.g.:

  task type My_Resource_Type is
    entry Do_Something_Critical;
  end;

  ...

  task body My_Resource_Type is
    ... -- resource state
  begin
    loop
      -- internal pre-processing
      select
        accept Do_Something_Critical do
          -- critical code here (blocking operations possible)
        exception
          when others =>
            -- reset resource state to something stable
        end;
        -- internal (checking and) post-processing
      or
        terminate;
      end select;
    end loop;
  end My_Resource_Type;

  ...

  The_Resource: My_Resource_Type;

  ...

  begin
    -- pre-processing specific to this point in execution
    The_Resource.Do_Something_Critical;
    -- post-processing specific to this point in execution
  end;

Of course, this is likely to be implemented by the compiler using
mutexes/semaphores. The point is, it's generally better to use a
higher-level construct like this, because it generally gives the compiler
more opportunity to catch bugs.

> The technique shown using a Limited_Controlled type to
> automatically seize and release the semaphore is a standard Ada95 idiom.

It may be a standard idiom, to some people, but that doesn't necessarily
make it the best approach. When the COBOL ALTER verb was invented, it was
standard idiom at the time for programs to modify their own code
dynamically. Nowadays, it is recognised that anyone using ALTER faces the
danger of self-lobotomy*.

Or, to put it another way, the standard idiom in this case doesn't seem to
address the problem of an exception leaving the resource in question in an
unstable state. Nor does it do anything to mitigate the effects of
accidentally omitting (or wrongly positioning) one of the seize or release
calls.

--
Best wishes,
Nick Roberts




*Eight months, nine hundred and fifty man hours, twenty three bottles of
painkillers, ninety five bottles of whiskey, two divorces, one and a half
garagefuls of listings, seventy severe arguments with the boss, and five
therapists later.

Or so ex CA Associates employees tell me, anyway.

:-o ;-)