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.chttps://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
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/87e63b21b2a6c375e93c...
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