Re: Uninterruptible (atomic) operation?

Re: Uninterruptible (atomic) operation?

[John McCabe]

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

>> In article <E25tK3.3G7@world.std.com> bobduff@world.std.com (Robert A Duff)
>> writes:
>>

<..snip..>

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

Just a brief note, but don't trust pragma shared (in Ada 83) to do
what would seem reasonable. I've learned through experience that this
is the case. The LRM 83 reference is very woolly. It's well worth
reading Robert Dewar's report on Shared Variables and Ada 9X issues
available from AdaIC on this matter.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Uninterruptible (atomic) operation?

[W. Wesley Groleau (Wes)]

:>  wwgrol> Can someone tell me the names if they exist of
:>  wwgrol> system calls to "hog the CPU" for a short time and release it.
:>
:> There are none (in general).
:>
:> Shared memory is only for use with *cooperating* processes. That is, you
:> know damn well all the processes are using the semaphore, because you wrote
:> them all. That's how it's done.

OK, let's put it another way:  The shared memory is updated only rarely,
but the reads are very frequent.  One of the processes reads it so often
that folks are concerned about the overhead.  The value they're reading
is used for communications timings.  If the writing process can "hog" the
cpu for the five to ten machine instructions necessary to do the writes,
then everyone else can "trust" the atomicity of the values.

(And if we used Ada-95 we could use pragma Atomic.)

(And if wishes were horses...)

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

Re: Uninterruptible (atomic) operation?

[Robert A Duff]

In article <9612091326.AA04263@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>(And if we used Ada-95 we could use pragma Atomic.)

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.

- Bob

Re: Uninterruptible (atomic) operation?

[Bob Gilbert]

In article <E25tK3.3G7@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <9612091326.AA04263@most>,
> W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
> >(And if we used Ada-95 we could use pragma Atomic.)
> 
> 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.
> 
> - Bob

Perhaps it is just too obvious, or I don't understand the
question, but isn't this sort of thing that protected types
(Ada 95) or critical regions of tasks (both Ada 83 and 95)
are all about?

- Another Bob

Re: Uninterruptible (atomic) operation?

[W. Wesley Groleau (Wes)]

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

Re: Uninterruptible (atomic) operation?

[Robert I. Eachus]

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.

--

					Robert I. Eachus

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

Re: Uninterruptible (atomic) operation?

[Robert S. White]

In article <EACHUS.96Dec10204319@spectre.mitre.org>, eachus@spectre.mitre.org 

...snip...  using Ada95

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

  OK. I can live with that.  In the past using Ada83 and a local (company 
generated - DO-178BB) Real Time Executive (RTE) I could do the following 
(assuming a record structure):

  (Potential) Writer:
  with ESR;
    ...
  ESR.Enter_Critical_Section;
  -- various updating operations on Object.
  ESR.Leave_Critical_Section;

  
  Reader:
  
  with ESR;
    ...
  ESR.Enter_Critical_Section;
  Temp := Object.all;
  ESR.Leave_Critical_Section;
  -- use value in temp.

  With the real time constraint that thou use'st a minimum (1/3 of a tick max) 
time within a critical section.  ESR = Executive Service Routine package.

  But what Robert Eachus suggests is semantically equivalent and inclusive in a 
new ISO standardized language rather than a older language and a unique RTE.

_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US --long/cheap alternate I-net address

Re: Uninterruptible (atomic) operation?

[Robert Dewar]

Wes asks

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


Look at the code more carefully. The writer is depending on being able
to do a series of operations on the value without any other writers getting
in the way.

The only thing that a reader needs is a guarantee of a consistent value.

pragma Atomic or Shared should NOT use an implementation that involves
a lock, implicit locks of this type are not at all in the spirit of what
is intended. If you need a lock, you must use task syncrhonization
primitives. the pragma is intended to identify cases where the hardware
does an atomic load or store with no additional overhead.

So, if the pragma is accepted, this approach does EXACTLY what you want.
If the pragma is rejected, then there is no cheap way of doing what you
want, particularly if you take the priority model of annex D seriously.

Re: Uninterruptible (atomic) operation?

[Robert I. Eachus]

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

Re: Uninterruptible (atomic) operation?

[Robert Dewar]

iJohn McCabe said

"Just a brief note, but don't trust pragma shared (in Ada 83) to do
what would seem reasonable. I've learned through experience that this
is the case. The LRM 83 reference is very woolly. It's well worth
reading Robert Dewar's report on Shared Variables and Ada 9X issues
available from AdaIC on this matter."


Well I don't quite know what JMcC would or would not find as seeming
reasonable, but, assuming an implementation of Ada 83 that respected
any conceivable interpretation of what pragma Shared means, the
particular use suggested here is entirely safe and appropriate in 
Ada 83 (as it is for Atomic in Ada 95)

Re: Uninterruptible (atomic) operation?

[J-P. Rosen]

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

>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 are running on a mono-processor, you can have the update
done by a surrogate task that runs at highest priority level.
+------------------------------------o-------------------------------------+
|   J-P. Rosen                       |    Rosen.Adalog@wanadoo.fr          |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+