From 7b05b88ce799fdba12caf6ba4e6419d3dc4702f6 Mon Sep 17 00:00:00 2001 From: Bobby Holley Date: Tue, 2 May 2017 12:38:12 -0700 Subject: [PATCH] Document the reasoning for the Acquire/Release handshake when dropping Arcs. --- src/liballoc/arc.rs | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/liballoc/arc.rs b/src/liballoc/arc.rs index 182a107e3f769..1df79074d3f4d 100644 --- a/src/liballoc/arc.rs +++ b/src/liballoc/arc.rs @@ -767,7 +767,18 @@ unsafe impl<#[may_dangle] T: ?Sized> Drop for Arc { // > through this reference must obviously happened before), and an // > "acquire" operation before deleting the object. // + // In particular, while the contents of an Arc are usually immutable, it's + // possible to have interior writes to something like a Mutex. Since a + // Mutex is not acquired when it is deleted, we can't rely on its + // synchronization logic to make writes in thread A visible to a destructor + // running in thread B. + // + // Also note that the Acquire fence here could probably be replaced with an + // Acquire load, which could improve performance in highly-contended + // situations. See [2]. + // // [1]: (www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html) + // [2]: (https://github.com/rust-lang/rust/pull/41714) atomic::fence(Acquire); unsafe {