On Thu, Apr 23, 2009 at 4:58 PM, John Dlugosz
I'm revamping my atomic_counter template (see < http://www.dlugosz.com/Repertoire/refman/Classics/atomic_counter_whitepa per.html#toptop>) and plan on exposing all the available "magic" (e.g. things you can't do in C++) op-codes in the atomic read-modify-write department, as primitives. Then, use those in the template class.
But, I have gained a deeper appreciation for some of the LOCKable instructions I never thought were interesting. For example, you can LOCK ADD, which changes the value in memory but doesn't return back what it was or became. What good is that? Directly translating to C++, none at all. But... you do get back some information. In assembly language, you see the flags. So, a thread can add something to the location, and although doesn't know what it became in general, at least know if this thread is the one that made it zero. Or, overflowed, or whatever. Those flags are the basis of if-statements in assembly language. So, given primitive calls that return the whole set of flags, it occurs to me to be able to harness that with a metaprogramming-like interface.
For example, I'm hesitant to implement something called operator &= that doesn't return the new value, but "something else" instead. I think the only interesting flag here is whether the result is zero. So bool operator&=(left,right) returning whether the result was non-zero would be very confusing, even if it did work right when used in an 'if' condition!
So, just brainstorming, x&=y would return something not directly usable, but does work with an overloaded ==, so if you were to write (x&=y)==0 the result would be what you expect from C++. Maybe it's not worth the effort. But if anyone wants to discuss it...
I see no reason to implement this as operator overload. Instead, I'd suggest using a namespace-scope function with a name that spells out what it does as clearly as possible. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode