Documentation for Acquire/Release handshake when dropping Arcs is misleading #62230
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
#41730 and previous changes added comments describing the reasoning for the
Acquire
fence synchronizing with theRelease
counter decrement before the content ofArc
is deallocated. It refers to Boost documentation as an authoritative source. Unfortunately, even that gets its wrong: there is nothing in the C11/C++ standards (which LLVM adheres to) that guarantees ordering of non-atomic operations in presence of atomic fences. The fences in the current implementation may still be needed to e.g. order operations between strong and weak counts. However, the burden of ensuring that a newly allocated data block cannot be accessed by other threads which use past allocations at the same location lies entirely on the allocator.The documentation of
Alloc
andGlobalAlloc
may also need to be updated with the obligation to provide this guarantee for the implementations of thread-safe allocators.The text was updated successfully, but these errors were encountered: