-
Notifications
You must be signed in to change notification settings - Fork 107
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
repr(transparent)
for UnsafeCell
#317
Comments
wyfo
added a commit
to wyfo/swap-buffer-queue
that referenced
this issue
Jul 12, 2023
Need tokio-rs/loom#317 to use loom (almost) everywhere
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I wanted to use
loom::cell::UnsafeCell
in my project, but i could not, because the loom implementation is notrepr(transparent)
, as it stores an additional state.Would it be possible to store the state in a global-like map, and use the pointer of the cell as the map key (parking_lot dies this kind of thing if I'm not mistaken).
Actually, I tried to implement a draft of this idea in a branch, and it works almost well, but there is one test failing:
unsafe_cell_ok_3
. The main difference between the current implementation and my draft is that cell state is initialized lazily when the first read/write access is done, instead of being initialized at creation (that's because moving the cell before using would change the pointer of the cell).However, in
unsafe_cell_ok_3
, when the cell state is lazily initialized, causality is not zeroed, which leads to an incorrect write access stored in the state. The issue comes from this lineloom/src/rt/cell.rs
Lines 88 to 100 in bcf4e84
VersionVec::new()
, and then all tests pass.So, I would like to ask why do we need to initialize cell state with causality?
The text was updated successfully, but these errors were encountered: