Proposal: provide cas and barriers symbols even without -threaded

[Carter Schonwald]

ryan, the relevant machinery on the C side is here, see
./includes/stg/SMP.h :
https://github.com/ghc/ghc/blob/7cc8a3cc5c2970009b83844ff9cc4e27913b8559/includes/stg/SMP.h

(unless i'm missing something)


On Fri, Jul 19, 2013 at 4:53 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Ryan,
> if you look at line 270, you'll see the CAS is a C call
> https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L270
>
>
> What Simon is alluding to is some work I started (but need to finish)
> http://ghc.haskell.org/trac/ghc/ticket/7883 is the relevant ticket, and
> I'll need to sort out doing the same on the native code gen too
>
> there ARE no write barrier primops, they're baked into the CAS machinery
> in ghc's rts
>
>
> On Fri, Jul 19, 2013 at 1:02 PM, Ryan Newton <rrnewton at gmail.com> 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"?
>>
>> 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/73be9cf1/attachment.htm>