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.
Anyway I've found the problem - it was caused by a subsequent GC
overwriting the values of
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.
On Fri, Oct 28, 2016 at 3:02 AM, Simon Marlow wrote:
> Hi Ryan, I don't think that's the issue.
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
Briefly looking at the code it seems like several global variables involved
should be volatile: n_capabilities, enabled_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
Simon Marlow writes:
> I haven't been able to reproduce the failure yet. :(
>
Indeed I've also not seen it in my own local builds. It's quite an
fragile failure.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
Simon Marlow writes:
> How many cores does the builder machine have? (this should make it easier
> for me to repro)
>
It looks like 8.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
Hi Simon,
It seems that setnumcapabilities001 still occassionally fails, although
this time by a different mode:
https://phabricator.haskell.org/harbormaster/build/14485/?l=100
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs