Proposal: provide cas and barriers symbols even without -threaded

[Ryan Newton]

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"?

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.

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

  -Ryan

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





On Fri, Jul 19, 2013 at 11:41 AM, Carter Schonwald <
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>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130719/df99ab40/attachment.htm>