You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to use loom::cell::UnsafeCell in my project, but i could not, because the loom implementation is not repr(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 does 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 line
, but I don't really understand it; why read/write accesses should be initialized with causality? I've tested to replace causality by 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:
wyfo
added a commit
to wyfo/swap-buffer-queue
that referenced
this issue
Jul 12, 2023
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 does 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: