std::atomic<unsigned> vs. InterlockedXxx

NTDEV
21

The document you’re referring to is for a VERY out of date architecture (ARMv6). The current architecture is Armv8.4-A Other than Windows CE/Windows Embedded Compact/Windows Mobile, etc, Windows doesn’t nor ever did run on an ARMv6 processor.

The “Exclusive” instructions are NOT the entire suite of atomic-like instructions in the modern Arm architectures. Those instructions implemented “measured atomicity”. Around Armv8.3-A (maybe Armv8.2-A) included the LSE (Large Scale Extensions) where, in addition to Load Acquire/Store Release semantics, true atomic operations were included. Things like the LD and ST family of instructions were added where can a number of different operations. These more modern instructions implement true “enforced atomicity”.

There is an excellent video set by Herb Sutter on this topic of atomicity, especially as to how it applies to the C++ standards. The videos are a few years old now but discuss much of this topic. He mentions the newer Arm instructions near the end of the second video. At the time he created his slide deck, LSE was very new.

Greg

22

@Ben_Craig said:
You just saw R3 of the paper. R4 should be published soon, and unique_ptr is there in its entirety. I realized that the problem wasn’t with the new and delete operators, it was with the default operator new and operator delete. unique_ptr doesn’t force the default allocator in any way.

Perfect! I agree that unique_ptr doesn’t really take any stance on memory allocation, nor does it have a strong dependency on C++ exceptions; as long as there’s some operator new and operator delete that is available, it should work. I think I recall that I got the unique_ptr from MSVC’s standard library to compile with the /kernel flag, once I ripped out some non-essential exception stuff.