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,2ef9ab4638027d85
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Uninterruptible (atomic) operation?
Date: 1996/12/13
Message-ID: <EACHUS.96Dec13181403@spectre.mitre.org>#1/1
X-Deja-AN: 203994887
references: <9612111939.AA14087@most>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-12-13T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <9612111939.AA14087@most> "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

  > This is pretty close.  But why do we need the lock?  Isn't that implied
  > by Atomic/Shared?  LRM 83 9.11 (11) "each of direct reading and direct
  > updating is implemented as an individual implementation."

  The lock is to get read-modify-write semantics for the writers.  The
readers need not use it, and you also don't need it for one writer
many readers paradigms, or when none of the writes depend on the
current value of the shared variable.  (The one writer, many readers
idiom comes up fairly often.  I've never found a practical use for the
later option though.)

  > 1. Typically, the hidden implementation of such is that a semaphore is
  > used during both write or read to keep out other writers and readers.
  > In the case of protected objects (which I can't use anyway, this is still
  > true, except multiple readers are allowed).  What I am trying to do,
  > is find a way for the writer to disable preemption, so that readers
  > are kept out even though the readers do not incur the overhead of the
  > semaphore.  That is, if the reader tries to read _during_the_write_
  > there will be a slight delay, but most of the time a read is as fast
  > as any other variable.

    This is what the idiom I posted gives you.  The readers get either
the old value, or a short wait while the value is overwritten.  Only
(potential) writers see the semaphore, and there are cases where you
can double-test to avoid the overhead when not needed:

    if Shared = For_Me
    then
      Acquire(Lock);
      if Shared = For_Me
      then
        Temp := Shared;
        Do_Something(Temp);
      end if;
      Release(Lock);
    end if;

  > 2. An Ada 83 (which I'm stuck with) solution to (1) may not work if
  > the reader and the writer are parts of independent Unix processes, and
  > the shared object is created by system calls.  At first, I thought of
  > the solution where the item shared is a pointer to the object, and
  > the writer could overwrite the pointer atomically, after non-atomically
  > updating/creating a new object.  Problem there is that the shared memory
  > is guaranteed to be the same address for all processes using it.  But
  > if it contains a pointer, the object pointed to in process X may be at
  > a virtual address that is used for something else by process Y.

   If you have shared memory, and you have a heap in shared memory,
and a way to guarantee that the object will be allocated in the shared
heap, you can use Ada 83 that way.  There are Ada 83 implementations
that allow you to do all three.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...