Octocontrabass wrote:
This is very easy to do: declare the reference count as an atomic type, e.g. using "std::atomic<long>" instead of "long". All operations on an atomic variable will be atomic unless you explicitly relax the memory order.
There is no such thing as std::atomic<> in bare metal. I have my own implementation which is what I am trying to debug here.
Octocontrabass wrote:
You don't need to change how you access an atomic variable unless you want to relax the memory order.
I know all about memory orders. I am just trying to narrow down what the problem is without using my std::atomic<> implementation (see
https://github.com/kiznit/rainbow-os/bl ... %2B/atomic).
Octocontrabass wrote:
Generally, you should use std::atomic instead of the __atomic builtins.
That's what I am trying to do, debug my implementation of std::atomic<>.
Octocontrabass wrote:
The __sync builtins are deprecated.
Yes they are. Was this not worth a try? They still compile just fine.
Octocontrabass wrote:
How did you convince Clang to not call GCC?
That doesn't seem to make any sense. I am not using GCC. Why would clang call GCC? What am I missing here?
Octocontrabass wrote:
You may need to pass "-mno-outline-atomics" to ensure lock-free atomic operations are inline.
The generated code is inlining the atomics. I don't see how that flag would do anything here. Using "-moutline-atomics" does produce link errors as expected (again, bare metal). I suppose I could implement the missing functions here and see if it helps with anything...
I appreciate you are trying to help, maybe I should have been more clear that this is kernel code (i.e. bare metal) and that I don't have an implementation of std::atomic<> provided by the compiler.