@@ -181,10 +181,29 @@ pub struct Mutex<T: ?Sized> {
181
181
data : UnsafeCell < T > ,
182
182
}
183
183
184
- // these are the only places where `T: Send` matters; all other
185
- // functionality works fine on a single thread.
184
+ /// `T` must be `Send` for a [`Mutex`] to be `Send` because it is possible to acquire
185
+ /// the owned `T` from the `Mutex` via [`into_inner`].
186
+ ///
187
+ /// [`into_inner`]: Mutex::into_inner
186
188
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
187
189
unsafe impl < T : ?Sized + Send > Send for Mutex < T > { }
190
+
191
+ /// `T` must be `Send` for [`Mutex`] to be `Sync`.
192
+ /// This ensures that the protected data can be accessed safely from multiple threads
193
+ /// without causing data races or other unsafe behavior.
194
+ ///
195
+ /// [`Mutex<T>`] provides mutable access to `T` to one thread at a time. However, it's essential
196
+ /// for `T` to be `Send` because it's not safe for non-`Send` structures to be accessed in
197
+ /// this manner. For instance, consider [`Rc`], a non-atomic reference counted smart pointer,
198
+ /// which is not `Send`. With `Rc`, we can have multiple copies pointing to the same heap
199
+ /// allocation with a non-atomic reference count. If we were to use `Mutex<Rc<_>>`, it would
200
+ /// only protect one instance of `Rc` from shared access, leaving other copies vulnerable
201
+ /// to potential data races.
202
+ ///
203
+ /// Also note that it is not necessary for `T` to be `Sync` as it is not possible
204
+ /// to acquire a `&T` from a [`Mutex`].
205
+ ///
206
+ /// [`Rc`]: crate::rc::Rc
188
207
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
189
208
unsafe impl < T : ?Sized + Send > Sync for Mutex < T > { }
190
209
@@ -211,8 +230,16 @@ pub struct MutexGuard<'a, T: ?Sized + 'a> {
211
230
poison : poison:: Guard ,
212
231
}
213
232
233
+ /// A [`MutexGuard`] is not `Send` to maximize platform portablity.
234
+ /// On platforms that use POSIX threads (commonly referred to as pthreads) there is a requirement to
235
+ /// release mutex locks on the same thread they were acquired.
236
+ /// For this reason, [`MutexGuard`] must not implement `Send` to prevent it being dropped from
237
+ /// another thread.
214
238
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
215
239
impl < T : ?Sized > !Send for MutexGuard < ' _ , T > { }
240
+
241
+ /// `T` must be `Sync` for a [`MutexGuard<T>`] to be `Sync`
242
+ /// because it is possible to get a `&T` from `&MutexGuard` (via `Deref`).
216
243
#[ stable( feature = "mutexguard" , since = "1.19.0" ) ]
217
244
unsafe impl < T : ?Sized + Sync > Sync for MutexGuard < ' _ , T > { }
218
245
0 commit comments