@@ -12,8 +12,8 @@ use core::ops::{Deref, DerefMut};
12
12
pub unsafe trait RawLock : Default + Send + Sync {
13
13
/// Raw lock's token type.
14
14
///
15
- /// We don't enforce Send/ Sync, as some locks may not satisfy it. We restrict them at
16
- /// Send/ Sync impl for [LockGuard].
15
+ /// We don't enforce ` Send`/` Sync` , as some locks may not satisfy it. We restrict them at
16
+ /// ` Send`/` Sync` impl for [` LockGuard` ].
17
17
type Token ;
18
18
19
19
/// Acquires the raw lock.
@@ -23,7 +23,7 @@ pub unsafe trait RawLock: Default + Send + Sync {
23
23
///
24
24
/// # Safety
25
25
///
26
- /// - `self` must be a an acquired lock.
26
+ /// - `self` must be an acquired lock.
27
27
/// - `token` must be from a [`RawLock::lock`] or [`RawTryLock::try_lock`] call to `self`.
28
28
unsafe fn unlock ( & self , token : Self :: Token ) ;
29
29
}
@@ -112,24 +112,28 @@ impl<L: RawLock, T> Drop for LockGuard<'_, L, T> {
112
112
// SAFETY: since `self` was created with `lock` and it's `token`, the `token` given to
113
113
// `unlock()` is correct.
114
114
unsafe { self . lock . inner . unlock ( token) } ;
115
+
116
+ // Note: Important that nothing is done to `data` after `unlock()`.
115
117
}
116
118
}
117
119
118
120
impl < L : RawLock , T > Deref for LockGuard < ' _ , L , T > {
119
121
type Target = T ;
120
122
121
123
fn deref ( & self ) -> & Self :: Target {
122
- // SAFETY: Having a `LockGuard` means the underlying lock is acquired, so the underlying
123
- // data is valid. Hence we can create a shared reference to it.
124
+ // SAFETY:
125
+ // - Existance of a `LockGuard` means the lock is acquired, so the data is valid.
126
+ // - Having a shared reference to the `LockGuard` implies there is no accessor making a
127
+ // mutable reference to the data.
124
128
unsafe { & * self . lock . data . get ( ) }
125
129
}
126
130
}
127
131
128
132
impl < L : RawLock , T > DerefMut for LockGuard < ' _ , L , T > {
129
133
fn deref_mut ( & mut self ) -> & mut Self :: Target {
130
- // SAFETY: Having a `LockGuard` means the underlying lock is acquired, so the underlying
131
- // data is valid. Having a mutable refererence to it implies that we are the only one with
132
- // access to the underlying data. Hence we can create a mutable reference to it .
134
+ // SAFETY:
135
+ // - Existance of a `LockGuard` means the lock is acquired, so the data is valid.
136
+ // - Having a mutable reference to the `LockGuard` implies there is no accessor to data .
133
137
unsafe { & mut * self . lock . data . get ( ) }
134
138
}
135
139
}
0 commit comments