-
Notifications
You must be signed in to change notification settings - Fork 113
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.
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
Add access guards to UnsafeCell
#219
Conversation
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
/// Any number of [`ConstPtr`]s may concurrently access a given [`UnsafeCell`]. | ||
/// However, if the [`UnsafeCell`] is accessed mutably (by | ||
/// [`UnsafeCell::with_mut`] or [`UnsafeCell::get_mut`]) while a [`ConstPtr`] | ||
/// exists, Loom will detect the concurrent mutable and immutable accesses and | ||
/// panic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while a
ConstPtr
exists
This is stronger than necessary. If you never use the ConstPtr
again after the mutable access, then it is sound.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's correct; the checking performed here is too strict, and it will fail on some access patterns that are actually valid. however, i don't really think there's a practical way to do finer-grained checking in loom
. something like miri could probably do it, but a library like loom essentially only has two ways of tracking the duration of an access: a closure, like the existing with
API, and RAII.
i think it's fine for this API to reject some valid accesses, as long as that's clearly documented. code which requires more fine-grained interleaving of accesses shouldn't use this API.
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
UnsafeCell
UnsafeCell
Anything I can do to help move this forwards? It would be really nice to have... (cc @carllerche) |
Signed-off-by: Eliza Weisman <[email protected]>
The new Loom version 0.5.4 has new APIs (see tokio-rs/loom#219) that make it possible to correctly simulate things that hand out `UnsafeCell` pointers where the mutable/immutable access outlives a closure. This makes it possible to have more correct tests for things like our `Mutex` implementation.
The new Loom version 0.5.4 has new APIs (see tokio-rs/loom#219) that make it possible to correctly simulate things that hand out `UnsafeCell` pointers where the mutable/immutable access outlives a closure. This makes it possible to have more correct tests for things like our `Mutex` implementation.
The new Loom version 0.5.4 has new APIs (see tokio-rs/loom#219) that make it possible to correctly simulate things that hand out `UnsafeCell` pointers where the mutable/immutable access outlives a closure. This makes it possible to have more correct tests for things like our `Mutex` implementation.
The new Loom version 0.5.4 has new APIs (see tokio-rs/loom#219) that make it possible to correctly simulate things that hand out `UnsafeCell` pointers where the mutable/immutable access outlives a closure. This makes it possible to have more correct tests for things like our `Mutex` implementation.
This branch adds the ability to access an
UnsafeCell
by returning a guard that tracks the lifetime of an*mut T
or*const T
. This allows pointers toUnsafeCell
s to be stored in data structures, or returned as part of a guard in user code, while still participating in Loom's access tracking.This branch still needs some tests & docs improvements, but I'm opening it as a draft for now to make sure this is the right approach.