Quantcast
Channel: Missed optimization opportunity or required behavior due to acquire-release memory ordering? - Stack Overflow
Viewing all articles
Browse latest Browse all 2

Answer by PaulR for Missed optimization opportunity or required behavior due to acquire-release memory ordering?

$
0
0

You could write it like this:

void test() {  theStack.stackFrames[1] = StackFrame{ "someFunction", 30 };      // A  theStack.stackTop.store(1, std::memory_order_release);           // B  someFunction();                                                  // C  theStack.stackTop.exchange(0, std::memory_order_acq_rel);        // D  theStack.stackFrames[1] = StackFrame{ "someOtherFunction", 35 }; // E  theStack.stackTop.store(1, std::memory_order_release);           // F  someOtherFunction();                                             // G  theStack.stackTop.exchange(0, std::memory_order_acq_rel);        // H}

This should provide the second guarantee you are looking for, namely that E may not be observed before D. Otherwise I think the compiler will have the right to reorder the instructions as you suggested.

Since the sampler thread "acquires" stackTop and it suspends the target thread before reading which should provide additional synchronization, it should always see valid data when stackTop is 1.

If your sampler did not suspend the target thread, or if suspension does not wait for the thread to be actually suspended (check this), I think a mutex or equivalent would be necessary to prevent the sampler from reading stale data after reading stack top as one (example if it was suspended by the scheduler at the wrong moment).

If you can rely on the suspend to provide synchronization and just need to constrain reordering by the compiler, you should have a look at std::atomic_signal_fence


Viewing all articles
Browse latest Browse all 2

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>