OK to write to pointer returned with consume semantics?

[GeoRanger]

Hello:

I think the typical usage pattern for using std::memory_order_consume is something like this:

std::atomic<int> state;
...
int x = state.load(std::memory_order_consume);
int y = x * slope; // correct because y depends on x

Would the following still be correct?

std::atomic<int *> state;
...
int * px = state.load(std::memory_order_consume);
*px = y / slope; // Does this break the dependency?

On one hand, I'd think this would be guaranteed to work because the memory being dereferenced to write the pointer "depends" on the pointer value, but on the other hand, it looks fishy to me and leaves me with some lingering doubts.

Thanks for any insight,
GeoRanger

[Marc G]

Specifying your own memory ordering is very advanced stuff.
Herb Sutter has a very nice two-part presentation on this: https://channel9.msdn.com/Shows/Goin...Weapons-1-of-2
Part one describes the C++ memory model.
Also, I would recommend not to play with memory ordering, unless you know exactly what you are doing. Usually, for most situations, using the default memory ordering is advised.

[wolle]

On one hand, I'd think this would be guaranteed to work because the memory being dereferenced to write the pointer "depends" on the pointer value, but on the other hand, it looks fishy to me and leaves me with some lingering doubts.

In my view, if you're writing an ordinary application it's better to stick with the basics. Use a standard mutex to allow threads access to a section of code in a thread-safe manner, at least as a first approximation. It's only if this results in a performance bottleneck you need to optimize. And in that case most often the best solution is a high level re-design rather than a faster synchronization mechanism.