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.

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

Merged
merged 9 commits into from
Dec 3, 2021
Merged

Add access guards to UnsafeCell #219

merged 9 commits into from
Dec 3, 2021

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Jul 16, 2021

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 to UnsafeCells 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.

hawkw added 3 commits July 16, 2021 11:16
Signed-off-by: Eliza Weisman <[email protected]>
Comment on lines +25 to +29
/// 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.
Copy link
Contributor

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.

Copy link
Member Author

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.

@hawkw hawkw marked this pull request as ready for review August 2, 2021 19:37
@hawkw hawkw requested a review from carllerche August 2, 2021 19:37
@hawkw hawkw changed the title [WIP] Add access guards to UnsafeCell Add access guards to UnsafeCell Aug 23, 2021
@hawkw
Copy link
Member Author

hawkw commented Nov 13, 2021

Anything I can do to help move this forwards? It would be really nice to have... (cc @carllerche)

@hawkw hawkw merged commit b70695a into master Dec 3, 2021
hawkw added a commit that referenced this pull request Dec 3, 2021
# 0.5.4 (December 3, 2021)

### Added

- cell: Add `ConstPtr` and `MutPtr` RAII guards to `UnsafeCell` (#219)

### Changed

- Improve error message when execution state is unavailable (such as
  when running outside of `loom::model`) (#242)
hawkw added a commit that referenced this pull request Dec 3, 2021
# 0.5.4 (December 3, 2021)

### Added

- cell: Add `ConstPtr` and `MutPtr` RAII guards to `UnsafeCell` (#219)

### Changed

- Improve error message when execution state is unavailable (such as
  when running outside of `loom::model`) (#242)
hawkw added a commit that referenced this pull request Dec 3, 2021
# 0.5.4 (December 3, 2021)

### Added

- cell: Add `ConstPtr` and `MutPtr` RAII guards to `UnsafeCell` (#219)

### Changed

- Improve error message when execution state is unavailable (such as
  when running outside of `loom::model`) (#242)
@Darksonn Darksonn deleted the eliza/cell-guards branch December 4, 2021 10:58
hawkw added a commit to hawkw/thingbuf that referenced this pull request Dec 7, 2021
Now that tokio-rs/loom#219 has merged, we can add
`Deref`/`DerefMut` for the `Ref` types without breaking
Loom's concurrent access checking! :D

This makes the `Ref` APIs much easier to work with.
hawkw added a commit to hawkw/mycelium that referenced this pull request Jan 2, 2022
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.
hawkw added a commit to hawkw/mycelium that referenced this pull request Jan 2, 2022
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.
hawkw added a commit to hawkw/mycelium that referenced this pull request Jan 2, 2022
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.
hawkw added a commit to hawkw/mycelium that referenced this pull request Jan 2, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants