@@ -54,16 +54,33 @@ const MAX_REFCOUNT: usize = (isize::MAX) as usize;
5454/// exception. If you need to mutate through an `Arc`, use [`Mutex`][mutex], 
5555/// [`RwLock`][rwlock], or one of the [`Atomic`][atomic] types. 
5656/// 
57- /// `Arc` uses atomic operations for reference counting, so `Arc`s can be 
58- /// sent between threads. In other words, `Arc<T>` implements [`Send`] 
59- /// as long as `T` implements [`Send`] and [`Sync`][sync]. The disadvantage is 
60- /// that atomic operations are more expensive than ordinary memory accesses. 
61- /// If you are not sharing reference-counted values between threads, consider 
62- /// using [`rc::Rc`][`Rc`] for lower overhead. [`Rc`] is a safe default, because 
63- /// the compiler will catch any attempt to send an [`Rc`] between threads. 
64- /// However, a library might choose `Arc` in order to give library consumers 
57+ /// ## Thread Safety 
58+ /// 
59+ /// Unlike [`Rc<T>`], `Arc<T>` uses atomic operations for its reference 
60+ /// counting  This means that it is thread-safe. The disadvantage is that 
61+ /// atomic operations are more expensive than ordinary memory accesses. If you 
62+ /// are not sharing reference-counted values between threads, consider using 
63+ /// [`Rc<T>`] for lower overhead. [`Rc<T>`] is a safe default, because the 
64+ /// compiler will catch any attempt to send an [`Rc<T>`] between threads. 
65+ /// However, a library might choose `Arc<T>` in order to give library consumers 
6566/// more flexibility. 
6667/// 
68+ /// `Arc<T>` will implement [`Send`] and [`Sync`] as long as the `T` implements 
69+ /// [`Send`] and [`Sync`]. Why can't you put a non-thread-safe type `T` in an 
70+ /// `Arc<T>` to make it thread-safe? This may be a bit counter-intuitive at 
71+ /// first: after all, isn't the point of `Arc<T>` thread safety? The key is 
72+ /// this: `Arc<T>` makes it thread safe to have multiple ownership of the same 
73+ /// data, but it  doesn't add thread safety to its data. Consider 
74+ /// `Arc<RefCell<T>>`. `RefCell<T>` isn't [`Sync`], and if `Arc<T>` was always 
75+ /// [`Send`], `Arc<RefCell<T>>` would be as well. But then we'd have a problem: 
76+ /// `RefCell<T>` is not thread safe; it keeps track of the borrowing count using 
77+ /// non-atomic operations. 
78+ /// 
79+ /// In the end, this means that you may need to pair `Arc<T>` with some sort of 
80+ /// `std::sync` type, usually `Mutex<T>`. 
81+ /// 
82+ /// ## Breaking cycles with `Weak` 
83+ /// 
6784/// The [`downgrade`][downgrade] method can be used to create a non-owning 
6885/// [`Weak`][weak] pointer. A [`Weak`][weak] pointer can be [`upgrade`][upgrade]d 
6986/// to an `Arc`, but this will return [`None`] if the value has already been 
@@ -74,6 +91,8 @@ const MAX_REFCOUNT: usize = (isize::MAX) as usize;
7491/// strong `Arc` pointers from parent nodes to children, and [`Weak`][weak] 
7592/// pointers from children back to their parents. 
7693/// 
94+ /// ## `Deref` behavior 
95+ /// 
7796/// `Arc<T>` automatically dereferences to `T` (via the [`Deref`][deref] trait), 
7897/// so you can call `T`'s methods on a value of type `Arc<T>`. To avoid name 
7998/// clashes with `T`'s methods, the methods of `Arc<T>` itself are [associated 
@@ -91,13 +110,13 @@ const MAX_REFCOUNT: usize = (isize::MAX) as usize;
91110/// 
92111/// [arc]: struct.Arc.html 
93112/// [weak]: struct.Weak.html 
94- /// [`Rc`]: ../../std/rc/struct.Rc.html 
113+ /// [`Rc<T> `]: ../../std/rc/struct.Rc.html 
95114/// [clone]: ../../std/clone/trait.Clone.html#tymethod.clone 
96115/// [mutex]: ../../std/sync/struct.Mutex.html 
97116/// [rwlock]: ../../std/sync/struct.RwLock.html 
98117/// [atomic]: ../../std/sync/atomic/index.html 
99118/// [`Send`]: ../../std/marker/trait.Send.html 
100- /// [sync ]: ../../std/marker/trait.Sync.html 
119+ /// [`Sync` ]: ../../std/marker/trait.Sync.html 
101120/// [deref]: ../../std/ops/trait.Deref.html 
102121/// [downgrade]: struct.Arc.html#method.downgrade 
103122/// [upgrade]: struct.Weak.html#method.upgrade 
0 commit comments