M**LOC doesn't act on standard types so it's really not relevant. I said this already. Jeff Sent from my iPhone

On Mar 14, 2014, at 11:49 AM, Jed Brown <[email protected]> wrote:

Jeff Hammond <[email protected]> writes:

...

There's an easy solution for "bad" ops: fall back to C&S implementation the way one does on any shared memory arch when a particular atomic isn't supported but C&S is.

This means that no mutexes are required, NICs that have HW support for NO_OP, REPLACE, SUM, XOR, etc. can use them, and when a user asks for something silly like PROD, the performance is degraded for those ops alone and not for anything else.

1. How does the above not justify the same for M**LOC?

2. Now we expect every system to have the equivalent of CMPXCHG16B and that basic types will never be longer than 16B (unless a longer atomic is made available)?