Re: file locking in Ada

Re: file locking in Ada

[Robert Dewar]

Michael Brenner said (answering a query about file locking)

<<Now, if you wish to have some operations in parallel and some locked, with
the ability to turn locking on and off, you will need to store the locking
state of each file in a data structure accessible to the file request task.
That data structure will be accessed at each file operation request. Based
on its value, either a parallel task will be issued, or the command will
be queued.>.

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.

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 :-)

file locking in Ada

[Neil Goodgame]

How do perform mutually exclusive file locking in Ada.

Neil Goodgame(goodganp@aston.ac.uk)

Re: file locking in Ada

[Michael F Brenner]

In any language, such as Ada or C, you can call an underlying operating
system or file management system, such as Mips OS, VxWorks, Desqview,
Apple OS, CP/M, Starlet, Linus, DOS, etc. 

Ada is a lanaguage which lets you implement file locking within the
language itself. Set up a task which processes all requests for files.
Lets say you are using this for a database management system with
file-at-a-time access, since you wish to have file locking instead of
record locking. Therefore your operations will be a subset of relational
algebra, such as the following: select, merge (or join), import, delete,
and update. Each of these operations would be an entry in the file
request task. No other software talks to the files except through
that file request task. The task processes the requests one at a time,
and that implements TOTAL file locking. 

Now, if you wish to have some operations in parallel and some locked, with
the ability to turn locking on and off, you will need to store the locking
state of each file in a data structure accessible to the file request task.
That data structure will be accessed at each file operation request. Based
on its value, either a parallel task will be issued, or the command will
be queued. 

Record locking is the same logical concept, but implementing it efficiently
is difficult because of the size of the problems where record locking is
useful, and because of the distributed nature of those problems. Therefore,
if you intended to ask about record locking, always use commercial software
to record lock the net.

Re: file locking in Ada

[Larry Kilgallen]

In article <5hglog$lf8@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> In any language, such as Ada or C, you can call an underlying operating
> system or file management system, such as Mips OS, VxWorks, Desqview,
> Apple OS, CP/M, Starlet, Linus, DOS, etc. 
> 
> Ada is a lanaguage which lets you implement file locking within the
> language itself. Set up a task which processes all requests for files.
> Lets say you are using this for a database management system with
> file-at-a-time access, since you wish to have file locking instead of
> record locking. Therefore your operations will be a subset of relational
> algebra, such as the following: select, merge (or join), import, delete,
> and update. Each of these operations would be an entry in the file
> request task. No other software talks to the files except through
> that file request task. The task processes the requests one at a time,
> and that implements TOTAL file locking. 

Ensuring that no other software accesses the file, however, is a local
problem unless you rely on an operating system guarantee.  Such an
operating system guarantee can only be foolproof if it uses inner
modes or other hardware protection (i.e., not DOS).

Larry Kilgallen

Re: file locking in Ada

[Robert A Duff]

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

Re: file locking in Ada

[Robert Dewar]

Bob Duff said

<<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?>>

How can you deadlock without doing a potentially blocking operation
Yes, if protected objects were orthogonal abstraction mechanisms, one
could certainly tell, but given the severe restrictions that are placed
on them, I don't see how you could possibly tell with a functional test.

Re: file locking in Ada

[Robert Dewar]

Robert Duff said

<<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?>>

One more thing Bob, remember ceiling locking when you try to construct
your test program, this ensures that a higher priority task cannot
preempt a lower priority task in the middle of a protected object.

Re: file locking in Ada

[Nick Roberts]

Neil Goodgame <goodganp@aston.ac.uk> wrote in article
<333BB430.BF8@aston.ac.uk>...
> How do perform mutually exclusive file locking in Ada.
> 
> Neil Goodgame(goodganp@aston.ac.uk)

I would suggest that this is an operating-system issue.

Are you going to be using I/O packages supplied with your compiler (such as
Ada.Text_IO, Ada.Sequential_IO, and Ada.Direct_IO, for example), or are you
going to develop your own? 

In the latter case, you will want to check to see what locking facilities
the operating system provides, and make use of them. In the former case,
you will want to check either the supplied documentation, or, failing that
the supplied source code (if it is supplied) to see: (a) whether the I/O
packages automatically do file locking; (b) whether they provide an option
for file locking; and (c) if so, whether it is adequate for your needs.

Nick.

Re: file locking in Ada

[Robert A Duff]

In article <dewar.859696916@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>How can you deadlock without doing a potentially blocking operation

I'm thinking about something like this: Protected objects This and That,
both with functions F and G.  Protected object This has a function F,
which calls That.F.  Protected object That has a function G which calls
This.G.  Both directions.  Now, if task 1 calls This.F, and task 2 calls
That.G, then is there a potential deadlock?  Suppose we have two
processors, and both happen at the same time, and This.F locks This, and
That.G locks That.  If those locks allow read-only access, then deadlock
is impossible.  But if the implementation converts those read-only locks
into "normal" read/write locks, then it is possible that task 1 holds
the lock on This, and task 2 holds the lock on That, and each is
contending for the lock on the other protected object -- hence deadlock.

Suppose This and That have the same ceiling.  Tasks 1 and 2 are both
running, since we have (at least) two processors (so we don't care what
priority they are).

My claim is that the RM says the above situation must not deadlock,
whereas, the intent of the language designers (including me!), was that
the above situation *might* deadlock.

>Yes, if protected objects were orthogonal abstraction mechanisms, one
>could certainly tell, but given the severe restrictions that are placed
>on them, I don't see how you could possibly tell with a functional test.

It seems to me that contending for locks on protected objects can cause
deadlock -- no need for entries, or other "potentially blocking ops".
After all, if F and G above were replaced with protected *procedures*,
then surely, deadlock is possible.

The two situations, "deadlock possible", and "deadlock impossible" are
semantically different.  (No need to produce a test where deadlock is
"inevitable", IMHO.)

- Bob

Re: file locking in Ada

[Robert A Duff]

In article <dewar.859697051@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>One more thing Bob, remember ceiling locking when you try to construct
>your test program, this ensures that a higher priority task cannot
>preempt a lower priority task in the middle of a protected object.

Yeah, but: The core language doesn't care about ceilings, and anyway,
you can always construct a test where all protected objects have the
same ceiling (which I did).

- Bob