On Fri, Sep 09, 2011 at 09:09:27PM -0400, Geert Bosch wrote:
> To be honest, I can't quite see the use of completely unordered
> atomic operations, where we not even prohibit compiler optimizations.
> It would seem if we guarantee that a variable will not be accessed
> concurrently from any other thread, we wouldn't need the operation
> to be atomic in the first place. That said, it's quite likely I'm
> missing something here.
E.g. OpenMP #pragma omp atomic just documents that the operation performed
on the variable is atomic, but has no requirements on it being any kind of
barrier for stores/loads to/from other memory locations. That is what I'd
like to use related sync operations for. Say
var2 = 5;
#pragma omp atomic update
var = var + 6;
var3 = 7;
only guarantees that you atomically increment var by 6, the var2 store can
happen after it or var3 store before it (only var stores/loads should be
before/after the atomic operation in program order, but you don't need any
barriers for it).
Of course if you use atomic operations for locking etc. you want to
serialize other memory accesses too (say acquire, or release, or full
barriers).
Jakub
