Re: Uninterruptible (atomic) operation?

[dewar@merv.cs.nyu.edu (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.