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,8eff44ec1bcf8433
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-11-01 23:11:16 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!newshub.northeast.verio.net!verio!dispose.news.demon.net!news.demon.co.uk!demon!pogner.demon.co.uk!zap!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Container reqs
Date: 31 Oct 2001 06:37:14 +0000
Organization: Pushface
Message-ID: <x7v3d40co2t.fsf@smaug.pushface.org>
References: <9qctpn$lil$1@news.huji.ac.il>
 <slrn9slt9m.i2.lutz@taranis.iks-jena.de> <3BCC01B1.18C18C98@free.fr>
 <3BCC6CB7.20BAA30D@boeing.com> <u3d4jtnq6.fsf@gsfc.nasa.gov>
 <9qi2c8$gpb$1@nh.pace.co.uk> <m7jsttod28l58b9betgcm8n6q5lue6oo5o@4ax.com>
 <3bded21b$0$32589$626a54ce@news.free.fr> <9rmm2n$q4e$1@nh.pace.co.uk>
NNTP-Posting-Host: localhost
X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98
X-Trace: news.demon.co.uk 1004685056 nnrp-12:18512 NO-IDENT
 pogner.demon.co.uk:158.152.70.98
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: 31 Oct 2001 06:37:14 GMT
X-Newsreader: Gnus v5.7/Emacs 20.7
Xref: archiver1.google.com comp.lang.ada:15617
Date: 2001-10-31T06:37:14+00:00
List-Id: <comp.lang.ada>

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Seems like that might unreasonably lock up access to some
> object. Also, it isn't clear to me how this would make the object
> task safe? Assume you have a class that the constructor/destructor
> acquire some semaphore. It gets globally declared such that two
> threads can access its functions. Does each thread have to
> check/acquire the semaphore before write operations? Or do you code
> a check of the semaphore into all the critical paths? It isn't clear
> to me how this is supposed to work....

The BCs use this scheme for the "synchronized" components.

Start with a Monitor, probably but not necessarily one per Container
to be locked. It's probably implemented using a protected type with
Seize and Release.

Now create a (Limited_)Controlled Lock type, constrained by an access
to this Monitor. Its Initialize Seizes the Monitor, and its Finalize
releases it.

  declare
    L : Lock (The_Monitor'access);
  begin
    -- do stuff
  end;

so L's Finalize _will_ get called on exit, and release the Monitor,
even if there's an exception.

With GNAT, you need to add a pragma Warnings (Off, L) because of
course it's not referenced.

Also, you hope that the compiler doesn't optimize L away -- I think
there is an AI which says not to if the type Lock is limited.

And I'm not sure what'll happen with ATC .. deep stuff here.