<div dir="ltr">I see, but the compiler has no business caching things across requestSync(), which can in principle change anything: even if the compiler could see all the code, it would find a pthread_condwait() in there.<div><div><br></div><div>Anyway I've found the problem - it was caused by a subsequent GC overwriting the values of gc_threads[].idle before the previous GC had finished releaseGCThreads() which reads those values.  Diff on the way...</div><div><br></div><div>Cheers</div><div>Simon</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 October 2016 at 11:58, Ryan Yates <span dir="ltr"><<a href="mailto:fryguybob@gmail.com" target="_blank">fryguybob@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Right, it is compiler effects at this boundary that I'm worried about, values that are not read from memory after the changes have been made, not memory effects or data races.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 3:02 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Ryan, I don't think that's the issue.  Those variables can only be modified in setNumCapabilities, which acquires *all* the capabilities before it makes any changes.  There should be no other threads running RTS code(*) while we change the number of capabilities.  In particular we shouldn't be in releaseGCThreads while enabled_capabilities is being changed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(*) well except for the parts at the boundary with the external world which run without a capability, such as rts_lock() which acquires a capability.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers</div><span class="m_6927157440210372653HOEnZb"><font color="#888888"><div class="gmail_extra">Simon</div></font></span><div><div class="m_6927157440210372653h5"><div class="gmail_extra"><br><div class="gmail_quote">On 27 Oct 2016 17:10, "Ryan Yates" <<a href="mailto:fryguybob@gmail.com" target="_blank">fryguybob@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Briefly looking at the code it seems like several global variables involved should be volatile: n_capabilities, enab<wbr>led_capabilities, and capabilities.  Perhaps in a loop like in scheduleDoGC the compiler moves the reads of n_capabilites or capabilites outside the loop.  A failed requestSync in that loop would not get updated values for those global pointers.  That particular loop isn't doing that optimization for me, but I think it could happen without volatile.<div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 9:18 AM, Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> writes:<br>
<br>
> I haven't been able to reproduce the failure yet. :(<br>
><br>
</span>Indeed I've also not seen it in my own local builds. It's quite an<br>
fragile failure.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>
</div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>