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-Thread: 103376,35d52809fb2aac8f
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.sun.com!news.sun.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 06 Oct 2008 02:24:51 -0500
Newsgroups: comp.lang.ada
Subject: Re: Naming convention to identify functions with side effects
References: 
 <5654ee5f-aa9f-4fff-87e0-45854b850f26@y38g2000hsy.googlegroups.com>
 <29ac62e1-78da-4048-ad95-8f88a29f7d31@z6g2000pre.googlegroups.com>
 <h9civa1o39f6$.79cdhcp3sfms$.dlg@40tude.net>
 <48e13f14$0$6610$9b4e6d93@newsspool3.arcor-online.net>
 <wvbrtzbvgorn.fsf@sun.com>
 <48e5e370$0$6615$9b4e6d93@newsspool3.arcor-online.net>
From: Ole-Hjalmar Kristensen
 <ole-hjalmar.kristensen@substitute_employer_here.com>
Organization: Sun Microsystems
Date: 06 Oct 2008 09:24:50 +0200
Message-ID: <wvbrk5cmgp8d.fsf@sun.com>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cache-Post-Path: news1nwk!unknown@khepri42.norway.sun.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
X-Usenet-Provider: http://www.giganews.com
X-Trace: 
 sv3-hybX927cSLlfzgDytl6bWpAPgoMbpQR8bzECsRO74qDwhoamdiVOXQLOUltZoSJEVxKo0MB3o2PwyUj!7Ond+tSMNabfUlRbWxuynC5/5UTnm80izfq9iAb1U/Pw315ObaSdD+J/
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.39
Xref: g2news1.google.com comp.lang.ada:2245
Date: 2008-10-06T09:24:50+02:00
List-Id: <comp.lang.ada>

Yes, this works fine as long as all callers respect the calling protocol, but I
have spent countless hours tracking down bugs which come from people
*not* respecting such protocols, so I do not really like such
solutions unless you can guarantee that the resource will be released
sooner or later. 

>>>>> "GB" == Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:

    GB> Ole-Hjalmar Kristensen wrote:
    >> How would you implement the lock in youre case? I prefer not to mess
    >> around with semaphores, but use protected objects instead. In that
    >> case keeping the lock across the two calls is not so trivial.

    GB> In a simple, maybe simplistic way I'd hide the lock.

    GB> package News26 is

    GB>    subtype URL is String;

    GB>    type Web_Resource is tagged limited private;
    GB>      -- ... Observe the calling protocol, which is
    GB>      --  Load -> Is_Loaded -> Discard

    GB>    function Is_Loaded (Page: Web_Resource) return Boolean;
    GB>    procedure Load (Page: in out Web_Resource; Location: URL);
    GB>    procedure Discard (Page: in out Web_Resource);

    GB> private

    GB>    protected type Resource is
    GB>       entry Seize;
    GB>       procedure Release;
    GB>    private
    GB>       Busy: Boolean := False;
    GB>    end Resource;

    GB>    type Web_Resource is tagged limited
    GB>       record
    GB>          Lock: Resource;
    GB>          -- ...
    GB>       end record;

    GB> end News26;

    GB> Procedure Load will then Seize the Lock.

    GB> Another scheme could, I think, be using Dmitry's Page_Cache
    GB> administrating the sequencing of calls by slot-wise locking
    GB> or some such.

-- 
   C++: The power, elegance and simplicity of a hand grenade.