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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9c78d085847f47af
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: file locking in Ada
Date: 1997/03/29
Message-ID: <E7tuD6.4n7@world.std.com>#1/1
X-Deja-AN: 229327446
References: <333BB430.BF8@aston.ac.uk> <5hglog$lf8@top.mitre.org>
 <dewar.859565840@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-03-29T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.859565840@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>If you want simulatneous reads and locked writes, an interesting possibility
>is to use a protected type, and use functions for the reads and procedures
>for the writes. Of course your implementation has to allow parallel function
>calls, which many implementations will not bother with.

Where does the RM allow implementations to not bother with parallel
protected function calls?  I know that the intent of the language
designers was to allow both -- one function locks out another, or one
function allows another to run in parallel.  But I don't see where the
RM says so.  It seems possible to write code that detects the difference
-- it might deadlock if a function grabs read/write access, when it
would not deadlock if it only grabs read-only access.  What am I
missing?

There's certainly no general permission to play games with lock.
E.g. if an implementation were to have only a single global lock, which
was used to protect all protected objects (or all PO's at the same
ceiling), that would be wrong.  No, each protected object is supposed to
have its own lock.

>Also, in some implementations, a file read/write might be declared a
>potentially blocking operation and not be permitted.
>
>It is a pity that protected records have these abstraction glitches :-)

This is another issue.  I must admit I have a lot of sympathy for
Robert's opinion on this point.  On the other hand, I can understand the
rationale, given that part of the reason for PO's in the first place,
was to allow extremely efficient implementation of the locking on
embedded no-OS systems.

By the way, the language defined I/O is potentially blocking -- no
implementation definedness about that (see 9.5.1(18)).  What's
implementation defined is whether or not the implementation chooses to
detect that error.  And of course the language doesn't specify anything
about I/O packages that aren't defined in the RM -- e.g. some user's I/O
package that interfaces to the OS directly.

- Bob