[M3devel] fetch_and_op?

[Jay K]

ok.

 

But notice that they offer both forms really since they also have "modifying asignment operators".
Is that useful/possible to expose?

 


http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2145.html

 


"The fetch-and-operation functions return the original stored value. This approach is required for fetch-and-inclusive-or and fetch-and-and because there is no means to compute to the original stored value. In contrast to the core functions, the modifying assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal assignment operators, though, the atomic assignments return values rather than references. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value. "

 


For now I'll probably just expose add, sub, xor, but not or and and.
We can do them later via a compareexchange loop (see winbase.h which
does something similar for different reasons: lack of intrinsics).

 


Still a ways away from calling this done, because modifying
m3x86.m3 so far requires a lot of guessing/patternmatching.
I don't understand e.g. what "locked" means (not the
one I introduced, what was there).

 


 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 21 Jan 2010 09:23:59 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] fetch_and_op?

I want to implement the <cstdatomic.h> soon-to-be standard.  That is defined as fetch_and_op.




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office  +1 765 494 6001  +1 765 494 6001  | Mobile  +1 765 427 5484  +1 765 427 5484 



On 21 Jan 2010, at 08:29, Jay K wrote:

(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp; pop *)


Tony, are you sure you want to return the old value, not the new value?
That's not great on x86.
I believe for "or" and "and", you end up having to do a compare exchange loops.
 
 
For xor, add, sub, you can compute the old value, ok.
But if caller wanted the old value, he can do that himself also.
Caller can also write a compare_exchange loop.
 
 
Therefore, I think it should be:
 
(* tmp := Mem [s1.A].t;
   Mem [s1.A].t := tmp op s0.u;
   s1.u := tmp op s0.u; pop *)

There is of course value in storing the value in mem and stack, since mem
can change right away.
 
 
 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100121/0f3714c0/attachment-0002.html>