Re: Uninterruptible (atomic) operation?

["W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM>]

> In article <E25tK3.3G7@world.std.com> bobduff@world.std.com (Robert A Duff)
> writes:
>
>   > Pragma Atomic is essentially the same thing as Ada 83's pragma Shared.
>   > I don't think it's what you want in this case.
>
>   Actually this is the case where pragma Shared or pragma Atomic can
> be used, if supported for the object type.  Wes just needs to lock the
> value while it is being modified.  The trick is to have a lock which
> all the potential modifiers respect, and to use pragma Atomic, and
> Atomic reads and writes, so that the readers can trust the value they
> see.
>
>     (Potential) Writer:
>
>        Acquire(lock);
>        Temp := Atomic_Object;
>        -- operations on Temp...
>        Atomic_Object := Temp;
>        Release(lock);
>
>     Reader:
>
>        Temp := Atomic_Object;
>        -- use value in temp.

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."

My (additional) problem is two-fold:

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.

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.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------