<div dir="ltr">Edward,<div><br></div><div>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.</div>

<div><br></div>
<div>All I would need would be linkable symbols for those noops (a la <a href="https://github.com/ghc/ghc/blob/master/rts/Inlines.c" target="_blank">Inlines.c</a>), not just the #defines that are currently in SMP.h</div>

<div><br></div><div>
I think providing these symbols <i>reliably</i> would be complementary to Carter&#39;s proposal to handle them better in the LLVM backend.  In fact, Carter&#39;s proposal is more motivation, for me to be using the &quot;official&quot; versions in my .cmm &quot;ccalls&quot;.  </div>


<div>   Right now I&#39;ve literally copy-pasted the relevant code from SMP.h, into C code called &quot;DUP_cas&quot;, &quot;DUP_write_barrier&quot; etc (yuck).  And these duplicated versions would be missed by the CMM-&gt;LLVM conversion Carter has proposed.</div>


<div><br></div><div>  -Ryan</div><div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 12:11 PM, Edward Z. Yang <span dir="ltr">&lt;<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I want to note something, which is that if we did link in<br>
cas/store_load_barrier, then your lockfree queue would always be<br>
synchronized, even if you didn&#39;t compile with -threaded.  Perhaps this<br>
is not a big deal, but it is generally nice to not pay the cost of<br>
synchronization when it is unnecessary.  So it would be better if there<br>
were threaded/nonthreaded variants which you could use instead.  How<br>
does that sound? (Fortunately, you are not inlining the functions, so<br>
it&#39;s totally possible for this to happen.  We&#39;d have a tougher row<br>
to hoe if you needed to inline these functions.)<br>
<br>
Edward<br>
<br>
Excerpts from Ryan Newton&#39;s message of Thu Jul 18 06:17:44 -0700 2013:<br>
<div><div>&gt; The &quot;atomic-primops&quot; library depends on symbols such as store_load_barrier<br>
&gt; and &quot;cas&quot;, which are defined in SMP.h.  Thus the result is that if the<br>
&gt; program is linked WITHOUT &quot;-threaded&quot;, the user gets a linker error about<br>
&gt; undefined symbols.<br>
&gt;<br>
&gt; The specific place it&#39;s used is in the &#39;foreign &quot;C&quot;&#39; bits of this .cmm code:<br>
&gt;<br>
&gt;<br>
&gt; <a href="https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm" target="_blank">https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm</a><br>



&gt;<br>
&gt; I&#39;m trying to explore hacks that will enable me to pull in those functions<br>
&gt; during compile time, without duplicating a whole bunch of code from the<br>
&gt; RTS.  But it&#39;s a fragile business.<br>
&gt;<br>
&gt; It seems to me that some of these routines have general utility.  In future<br>
&gt; versions of GHC, could we consider linking in those routines irrespective<br>
&gt; of &quot;-threaded&quot;?<br>
&gt;<br>
&gt;   -Ryan<br>
</div></div></blockquote></div><br></div></div>