<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
No. Other sizes are often available such as 8, 16, 32 (on 64bit systems), 64 (on 32bit systems), 128 (on 64bit systems).<br>Maybe not 8, but there readily available examples of the others.<br><br>Search the web for:<br>  _InterlockedIncrement16 http://msdn.microsoft.com/en-us/library/2ddez55b.aspx <br>  _InterlockedCompareExchange64 http://msdn.microsoft.com/en-us/library/ttk2z1ws%28VS.85%29.aspx <br>  _InterlockedCompareExchange128 http://msdn.microsoft.com/en-us/library/bb514094.aspx <br><br>Some of this requires "newer" processors, for varying definitions of "newer" (including "fairly old").<br><br> - Jay<br><br><br>> Date: Sun, 20 Dec 2009 19:02:48 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Proposed Atomic Word.T interfaces.<br>> <br>> <br>> <br>> Tony Hosking wrote:<br>> > Thanks for the typo fixes.<br>> > <br>> > On 20 Dec 2009, at 11:44, Rodney M. Bates wrote:<br>> > <br>> >> To be legal on ADDRESS, either another parallel interface or a set of parallel<br>> >> procedures would be needed.  Or else, this interface would have to be known to<br>> >> the core language and allow predefined overloading, similar to builtin operators<br>> >> and functions.  The syntax could still be that of an interface.  I don't think<br>> >> any existing required interfaces do this now.<br>> > <br>> > Perhaps better to make it a generic interface and instantiate for ADDRESS and Word.T:<br>> <br>> And would it be illegal to try to instantiate with any other type?  I presume it would<br>> have to be a native word sized value for the implementation, and the Fetch operations<br>> would not have meaning for most other types.<br>> <br>> Also, would the corresponding MODULE and its instantiations not be written in M3,<br>> but just builtin to the compiler, like Word?<br>> <br>> > <br>> > GENERIC INTERFACE Atomic(Rep);<br>> > <br>> > TYPE T = Rep.T;<br>> > <br>> > TYPE<br>> >   Order = { Relaxed, Release, Acquire, AcquireRelease, Sequential };<br>> >   (* "Relaxed": The operation does not order memory.<br>> > <br>> >      "Release": Performs a release operation on the affected memory locations,<br>> >      thus making regular memory writes visible to other threads through the<br>> >      variable to which it is applied.<br>> > <br>> >      "Acquire": Performs an acquire operation on the affected memory<br>> >      locations, thus making regular memory writes in other threads released<br>> >      through the atomic variable to which it is applied, visible to the<br>> >      current thread.<br>> > <br>> >      "AcquireRelease": The operation has both acquire and release semantics.<br>> > <br>> >      "Sequential": The operation has both acquire and release semantics, and<br>> >      in addition, has sequentially-consistent operation ordering. *)<br>> > <br>> > CONST IsLockFree = Rep.IsLockFree;<br>> >   (* True if the operations are lock-free, false otherwise. *)<br>> > <br>> > PROCEDURE Store(VAR var: T; val: T; order := Order.Sequential);<br>> >   (* Atomically replace the value in "var" with "val".  Memory is affected as<br>> >      per "order".  The "order" shall be neither "Acquire" nor<br>> >      "AcquireRelease". *)<br>> > <br>> > PROCEDURE Load(READONLY var: T; order := Order.Sequential): T;<br>> >   (* Atomically return the value in "var".  Memory is affected as per "order".<br>> >      The "order" shall be neither "Release" nor "AcquireRelease". *)<br>> > <br>> > PROCEDURE Swap(VAR var: T; val: T; order := Order.Sequential): T;<br>> >   (* Atomically replace the value in "var" with "val". Returns the value of<br>> >      "var" immediately before the effects. Memory is affected as per order.<br>> >      This is a read-modify-write operation and synchronizes with any<br>> >      evaluation that reads the updated value. *)<br>> > <br>> > PROCEDURE CompareSwap(VAR var, expected: T;<br>> >                       desired: T; order := Order.Sequential): BOOLEAN;<br>> >   (* Atomically, compares the value in "var" for equality with that in<br>> >      "expected", and if true, replaces the value in "var" with "desired", and<br>> >      if false, updates the value in "expected" with the value in "var".<br>> >      Returns the result of the comparison.  The "order" shall be neither<br>> >      "Release" nor "AcquireRelease".  This is a read-modify-write operation<br>> >      and synchronizes with any evaluation that reads the updated value.  The<br>> >      effect of the CompareSwap operation is:<br>> > <br>> >      IF var = expected THEN var := desired ELSE expected := var;<br>> > <br>> >      The CompareSwap operation may fail spuriously, that is return false while<br>> >      leaving the value in "expected" unchanged.  A consequence of spurious<br>> >      failure is that nearly all uses of CompareSwap will be in a loop:<br>> > <br>> >      expected := Atomic.Load(current);<br>> >      DO<br>> >        desired := function(expected);<br>> >      WHILE NOT Atomic.CompareSwap(current, expected, desired);<br>> >   *)<br>> > <br>> > PROCEDURE Fence(VAR var: T; order := Order.Sequential);<br>> >   (* Memory is affected as per "order".  Synchronizes with any operation on<br>> >      the same variable.  The "order" shall not be "Relaxed". *)<br>> > <br>> > PROCEDURE FetchPlus (VAR var: T; incr: T; order := Sequential): T;<br>> > PROCEDURE FetchMinus(VAR var: T; decr: T; order := Sequential): T;<br>> > PROCEDURE FetchOr   (VAR var: T; mask: T; order := Sequential): T;<br>> > PROCEDURE FetchXOr  (VAR var: T; mask: T; order := Sequential): T;<br>> > PROCEDURE FetchAnd  (VAR var: T; mask: T; order := Sequential): T;<br>> >   (* Atomically replace the value in "var" with the result of the operation<br>> >      applied to the value in "var" and the given operand.  Memory is affected<br>> >      as per "order".  These operations are read-modify-write operations and<br>> >      synchronize with any evaluation that reads the updated value.  Returns<br>> >      the value of "var" immediately before the effects.<br>> > <br>> >      For signed integral types, arithmetic is defined to use two's-complement<br>> >      representation. There are no undefined results.  For address types, the<br>> >      result may be an undefined address, but the operations otherwise have no<br>> >      undefined behavior. *)<br>> > <br>> > END Atomic.<br>> > <br>> > <br>                                         </body>
</html>