[M3devel] fetch_and_op?

[Tony Hosking]

Wrong link.  I'm talking C not C++.

Here's the C link:

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf

PS I am shortly about to change the specs on compare exchange in M3CG_Ops.i3.  Stay tuned.


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




On 21 Jan 2010, at 17:30, Jay K wrote:

> 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/b17f3a47/attachment-0002.html>