Edward,

This makes sense to me.  Especially because eliding-synchronization is already the convention followed in SMP.hs, where, for example, write_barrier becomes noops if !THREADED_RTS.

All I would need would be linkable symbols for those noops (a la Inlines.c), not just the #defines that are currently in SMP.h

I think providing these symbols reliably would be complementary to Carter's proposal to handle them better in the LLVM backend.  In fact, Carter's proposal is more motivation, for me to be using the "official" versions in my .cmm "ccalls".  
   Right now I've literally copy-pasted the relevant code from SMP.h, into C code called "DUP_cas", "DUP_write_barrier" etc (yuck).  And these duplicated versions would be missed by the CMM->LLVM conversion Carter has proposed.

  -Ryan




On Thu, Jul 18, 2013 at 12:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
I want to note something, which is that if we did link in
cas/store_load_barrier, then your lockfree queue would always be
synchronized, even if you didn't compile with -threaded.  Perhaps this
is not a big deal, but it is generally nice to not pay the cost of
synchronization when it is unnecessary.  So it would be better if there
were threaded/nonthreaded variants which you could use instead.  How
does that sound? (Fortunately, you are not inlining the functions, so
it's totally possible for this to happen.  We'd have a tougher row
to hoe if you needed to inline these functions.)

Edward

Excerpts from Ryan Newton's message of Thu Jul 18 06:17:44 -0700 2013:
> 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/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"?
>
>   -Ryan