Memory ordering and thunk update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Memory ordering and thunk update

Ben Gamari-2
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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment