Memory ordering and thunk update

Ben Gamari ben at smart-cactus.org
Sun Feb 10 00:01:51 UTC 2019


Hi Simon and Peter,

I just wanted to draw your attention to !337 [1], where I try to fix
#15994. While it's possible I have missed something, it looks to me like
there has been a bug lurking here for quite some time. In particular on
a weak memory model machine we do not place a write barrier between the
construction of the result of a thunk evaluation and making the results
visible to other cores via the indirection's indirectee field. This
essentially means that a thread looking at the indirectee may
essentially see uninitialized memory.

Specifically, updateWithIndirection is currently:

    # Evaluation result p2 initialized by caller
    ...
    ((StgInd *)p1)->indirectee = p2;
    write_barrier();
    SET_INFO(p1, &stg_BLACKHOLE_info);
    ...

whereas I think this should rather be

    # Evaluation result p2 initialized by caller
    ...
    write_barrier();
    ((StgInd *)p1)->indirectee = p2;
    SET_INFO(p1, &stg_BLACKHOLE_info);
    ...

I describe the reasoning for this in more detail in the Note added in
!337.

All-in-all, I'm rather surprised to find this bug. While we won't see
this issue manifest on x86_64 due to this architecture's memory model,
we have long supported ARM, PowerPC, and SPARC, all of which have
weakly-ordered execution modes. I can't find any relevant open tickets
from these platforms. The fact that this wasn't noticed on these
platforms makes me wonder whether I am just missing something.

Let me know what you think.

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/337
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190209/6f6175fc/attachment.sig>


More information about the ghc-devs mailing list