Proposal: provide cas and barriers symbols even without -threaded

[Ryan Newton]

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<https://github.com/ghc/ghc/blob/master/rts/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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130720/a34679dd/attachment.htm>