NOTE: I have not followed the series from start to finish, but rather have been browsing the Youtube playlists that revolve around specific functionality (Thank you so much for doing that Casey). As a result my own individual code base does not mirror HH's (Virtual OS-like platform abstraction instead of Casey's implementation, Vulkan based rendering (eventually) rather than winapi/OpenGL based rendering, etc) and i might not be quite caught up with changes Casey might have made after the videos listed in a specific playlist.
On day 124, Casey implemented memory barriers and explained how they prevented memory reordering done by the compiler. _Read/WriteBarrier are VC++ only similar to how asm volatile is GCC only. Plus The MSDN is trying to suggest using the std::atomic types which means using the c++ std lib (which I like Casey wanted to avoid as much as possible).
I do not like using any deprecated functions/types/apis/etc at risk of future versions a thing A no longer supporting them resulting in code having to be rewritten, plus the _Read/WriteBarrier properties are not even available to me because i am using MinGW-64 rather than VC++. GCC's asm volatile might work, but regardless of GCC or VC++ much code/#defines/refactoring will need to be done in the event that i want to use different compilers to maximize portability (GCC is deprecated in Android NDK for example in exchange for Clang)
Doing deeper research led me too a third solution; just use a function call, but that seems to dirty to not be viable without some form of major drawback.
1 2 3 4 5 6 | void doSomeStuff(Foo* foo) { foo->bar = 5; sendValue(123); // prevents reordering of neighboring assignments foo->bar2 = foo->bar; } |
Rather than all these explicit compiler barriers/std c++ atomics, could i just use a function call?
Link to the forum post i found discussing using a function call as a barrier.