CODEWITHSUNDEEP
c++multithreadingvisual-c++memory-barriersstdatomic
Nimo
Nimo

Reputation: 324

Deprecation of _writeBarrier()

I've recently upgraded the version of visual studio (2019) I'm working on and am recompiling an fairly old codebase written by a previous developer. I'm getting the following issue during compilation:

C3861: '_WriteBarrier': identifier not found

This originates from the following block of code:

inline void SetValueWithRelease(volatile unsigned int* p, int newval)
{ *p = newval; _WriteBarrier(); }

My understanding of _writebarrier is very limited, but I believe the purpose of that intrinsic is to ensure that, in a multi-threaded environment, the compiler doesn't try to be to "clever" in optimizing the code and ends up allowing other threads to inadvertently use an uninstantiated version of p.

But as for getting past this issue of deprecation, from what I've read, my best option is to use atomic_thread_fence: https://learn.microsoft.com/en-us/cpp/standard-library/atomic-functions?view=vs-2019#atomic_thread_fence

Assuming that's correct, I'm inclined to use the "memory_order_seq_cst" memory order option in this function, but I'm not sure.

I'd appreciate any input or direction to clear explanations.

Upvotes: 2

Views: 649

Answers (1)

Peter Cordes
Peter Cordes

Reputation: 365277

Ideally you could convert from hand-rolled atomics with volatile into using atomic<int> *p with p->store(newval, std::memory_order_release); Otherwise you're at the mercy of the compiler as far as interaction between volatile and atomic thread fences.

I'd guess atomic_thread_fence(std::memory_order_release) should work fine on existing compilers to make a hand-rolled relaxed store with volatile into a release-store.

Upvotes: 4

Related Questions