Closed wavewave closed 4 months ago
For context, https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10628 removed these RTS functions.
What is the recommended alternative to using these functions?
In general we have been trying to move away from explicit barriers entirely. {ACQUIRE,RELEASE,SEQ_CST}_FENCE
exist if you really need a barrier but I would strongly recommend using a ordered atomic operation instead (e.g. ACQUIRE_LOAD
, RELEASE_STORE
, or similar).
For even further context, https://github.com/rrnewton/haskell-lockfree/commit/4f259b5072a0b1d9701139a1221cca4e7eeef975 is the commit that introduced the use of explicit memory barriers in atomic-primops
. Judging from this, it appears that the main consumer is chaselev-deque
. If push came to shove, we could just remove the memory barriers from atomic-primops
. It would break chaselev-deque
, but chaselev-deque
is already broken.
Fixed in #89. I've uploaded these changes to Hackage as atomic-primops-0.8.5
.
It turns out that this fix wasn't quite right as the foreign import
s were marked as ccall
whereas they should have been prim
, leading to https://gitlab.haskell.org/ghc/ghc/-/issues/24595. I will fix.
@bgamari addressed the issue in https://github.com/rrnewton/haskell-lockfree/issues/88#issuecomment-2021769236 as part of #90. I've released these changes to Hackage as part of atomic-primops-0.8.6
.
There is still an issue with these primops. See: https://gitlab.haskell.org/ghc/ghc/-/issues/25010
Reopening in light of https://gitlab.haskell.org/ghc/ghc/-/issues/25010.
I've uploaded atomic-primops-0.8.8
to Hackage, which contains the changes from #91. Thanks for the patch!
therefore, atomic-primops should be changed correspondingly.
https://gitlab.haskell.org/ghc/ghc/-/commits/master/rts/include/stg/SMP.h?ref_type=heads
https://gitlab.haskell.org/ghc/ghc/-/commit/7a7d326cdd5b640c3d40266b88f66b2a2dfeccbe
and
store_load_barrier
andwrite_barrier
are also removed.