[M3devel] Proposed Atomic Word.T interfaces.
Rodney M. Bates
rodney_bates at lcwb.coop
Sun Dec 20 17:44:38 CET 2009
Tony Hosking wrote:
> Here is my updated proposal for Modula-3 Atomic Word.T.
> These are based on what we can have implemented from libatomic_ops, a
> prototype implementation for the C++ memory model standardization
> process. At the moment they are not gcc intrinsics, but I expect to see
> that coming as the standard progresses.
>
> INTERFACE Atomic;
>
> IMPORT Word;
>
> TYPE T = Word.T;
>
> TYPE
> Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential };
> (* "Relaxed": The operation does not order memory.
>
> "Release": Performs a release operation on the affected memory
> locations,
> thus making regular memory writes visible to other threads through the
> variable to which it is applied.
>
> "Acquire": Performs an acquire operation on the affected memory
> locations, thus making regular memory writes in other threads released
> through the atomic variable to which it is applied, visible to the
> current thread.
>
> "AcquireRelease": The operation has both acquire and release semantics.
>
> "Sequential": The operation has both acquire and release semantics, and
> in addition, has sequentially-consistent operation ordering. *)
>
> CONST IsLockFree = RTMachine.IsLockFree;
> (* True if the operations are lock-free, false otherwise. *)
>
> PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential);
> (* Atomically replace the value in "var" with "val". Memory is
> affected as
> per "order". The "order" shall be neither "Acquire" nor
> "AcquireRelease". *)
>
> PROCEDURE Load(READONLY var: T; order := Order.Sequential): T;
> (* Atomically return the value in "var". Memory is affected as per
> "order".
> The "order" shall be neither "Release" nor "AcquireRelease". *)
>
> PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T;
> (* Atomically replace the value in "var" with "val". Returns the value of
> "var" immediately before the effects. Memory is affected as per order.
> This is a read-modify-write operation and synchronizes with any
> evaluation that reads the updated value. *)
>
> PROCEDURE CompareSwap(VAR var, expected: T;
> desired: T; order := Order.Sequential): BOOLEAN;
> (* Atomically, compares the value in "var" for equality with that in
> "expected", and if true, replaces the value in "var" with
> "desired", and
> if false, updates the value in "expected" with the value in "var".
> Returns the result of the comparison. The "order" shall be neither
> "Release" nor "AcquireRelease". This is a read-modify-write operation
> and synchronizes with any evaluation that reads the updated value. The
> effect of the CompareSwap operation is:
>
> IF var = expected THEN var := desired ELSE expected := var;
>
> The CompareSwap operation may fail spuriously, that is return false
> while
> leaving the value in "expected" unchanged. A consequence of spurious
> failure is that nearly all uses of CompareSwap will be in a loop:
>
> expected := Atomic.Load(current);
> DO
> desired := function(expected);
> WHILE NOT Atomic.CompareSwap(current, expected, desired);
> *)
>
> PROCEDURE Fence(VAR var: T; order := Order.Sequential);
> (* Memory is affected as per "order". Synchronizes with any operation on
> the same variable. The "order" shall not be "Relaxed". *)
>
> PROCEDURE FetchPlus (VAR var; incr: T; order := Sequential): T;
PROCEDURE FetchPlus (VAR var:T; incr: T; order := Sequential): T;
Presumably -------------------^? Similarly in all the Fetch* procs.
> PROCEDURE FetchMinus(VAR var; mask: T; order := Sequential): T;
PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T;
Presumably ------------------------^ would be more expressive?
> PROCEDURE FetchOr (VAR var; mask: T; order := Sequential): T;
> PROCEDURE FetchXOr (VAR var; mask: T; order := Sequential): T;
> PROCEDURE FetchXAnd (VAR var; mask: T; order := Sequential): T;
> (* Atomically replace the value in "var" with the result of the operation
> applied to the value in "var" and the given operand. Memory is
> affected
> as per "order". These operations are read-modify-write operations and
> synchronize with any evaluation that reads the updated value. Returns
> the value of "var" immediately before the effects.
>
> For signed integral types, arithmetic is defined to use
> two's-complement
> representation. There are no undefined results. For address types, the
> result may be an undefined address, but the operations otherwise
> have no
> undefined behavior. *)
To be legal on ADDRESS, either another parallel interface or a set of parallel
procedures would be needed. Or else, this interface would have to be known to
the core language and allow predefined overloading, similar to builtin operators
and functions. The syntax could still be that of an interface. I don't think
any existing required interfaces do this now.
>
> END Atomic.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
More information about the M3devel
mailing list