Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the reasoning for the Acquire/Release handshake when dropping Arcs. #41730

Merged
merged 1 commit into from
May 4, 2017
Merged

Document the reasoning for the Acquire/Release handshake when dropping Arcs. #41730

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions src/liballoc/arc.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -767,7 +767,18 @@ unsafe impl<#[may_dangle] T: ?Sized> Drop for Arc<T> {
// > 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<T>. 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 {
Expand Down