Proposal: provide cas and barriers symbols even without -threaded

[Simon Marlow]

On 19/07/13 18:02, Ryan Newton wrote:
> Yes, I'd absolutely rather not suffer C call overhead for these
> functions (or the CAS functions).  But isn't that how it's done
> currently for the casMutVar# primop?
>
> https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L265
>
> To avoid the overhead, is it necessary to make each primop in-line
> rather than out-of-line, or just to get rid of the "ccall"?

The best thing would be to get rid of the overhead, but the native code 
generators need to be taught how to generate code for cas.

> Another reason it would be good to package these with GHC is that I'm
> having trouble building robust libraries of foreign primops that work
> under all "ways" (e.g. GHCI).  For example, this bug:
>
> https://github.com/rrnewton/haskell-lockfree-queue/issues/10
>
> If I write .cmm code that depends on RTS functionality like
> stg_MUT_VAR_CLEAN_info, then it seems to work fine when in compiled mode
> (with/without threading, profiling), but I get link errors from GHCI
> where these symbols aren't defined.

That's a bug, I'll fix it.

> I've got a draft of the relevant primops here:
>
> https://github.com/rrnewton/haskell-lockfree-queue/blob/master/AtomicPrimops/cbits/primops.cmm
>
> Which includes:
>
>   * variants of CAS for MutableArray# and MutableByteArray#
>   * fetch-and-add for MutableByteArray#
>
> Also, there are some tweaks to support the new "ticketed" interface for
> safer CAS:
>
> http://hackage.haskell.org/packages/archive/atomic-primops/0.3/doc/html/Data-Atomics.html#g:3
>
> I started adding some of these primops to GHC proper (still as
> out-of-line), but not all of them.  I had gone with the foreign primop
> route instead...
>
> https://github.com/rrnewton/ghc/commits/master

Ok, will you make a ticket and attach the patches when you're ready?

>    -Ryan
>
> P.S. Where is the write barrier primop?  I don't see it listed in
> prelude/primops.txt.

It's not a primop.  Perhaps it should be.  It's a MachOp in Cmm, you 
write it as

   prim write_barrier;

Cheers,
	Simon




>
> On Fri, Jul 19, 2013 at 11:41 AM, Carter Schonwald
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>
>     I guess I should find the time to finish the CAS primop work I
>     volunteered to do then. Ill look into in a few days.
>
>
>     On Friday, July 19, 2013, Simon Marlow wrote:
>
>         On 18/07/13 14:17, Ryan Newton wrote:
>
>             The "atomic-primops" library depends on symbols such as
>             store_load_barrier and "cas", which are defined in SMP.h.
>               Thus the
>             result is that if the program is linked WITHOUT "-threaded",
>             the user
>             gets a linker error about undefined symbols.
>
>             The specific place it's used is in the 'foreign "C"' bits of
>             this .cmm code:
>
>             https://github.com/rrnewton/__haskell-lockfree-queue/blob/__87e63b21b2a6c375e93c30b98c28c1__d04f88781c/AtomicPrimops/__cbits/primops.cmm
>             <https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm>
>
>             I'm trying to explore hacks that will enable me to pull in those
>             functions during compile time, without duplicating a whole
>             bunch of code
>             from the RTS.  But it's a fragile business.
>
>             It seems to me that some of these routines have general
>             utility.  In
>             future versions of GHC, could we consider linking in those
>             routines
>             irrespective of "-threaded"?
>
>
>         We should make the non-THREADED versions EXTERN_INLINE too, so
>         that there will be (empty) functions to call in rts/Inlines.c.
>           Want to submit a patch?
>
>         A better solution would be to make them into primops.  You don't
>         really want to be calling out to a C function to implement a
>         memory barrier. We have this for write_barrier(), but none of
>         the others so far.  Of couse that's a larger change.
>
>         Cheers,
>                  Simon
>
>
>
>         _________________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org
>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>
>