core::pipes::try_recv_ missing an acquire barrier

[talchas]

fn try_recv_<T:Owned>(p: &mut Packet<T>) -> Option<T> {
    // optimistic path
    match p.header.state {
      Full => {
        let payload = replace(&mut p.payload, None);

The read of p.header.state needs to be an acquire barrier probably via atomic_load_acq to ensure it comes before the read of p.payload, matching with the release by swap_state_rel in send.

[bblum]

This is relevant on architectures with out-of-order memory semantics (ARM, not x86). @eholk and I designed this fastpath before the ARM port came around.

Nominating for production-ready milestone.

[bblum]

@talchas points out that it might also be broken on x86 if LLVM decides to reorder the instruction. So a proper fix (i.e. one that maintains the fastpath performance) would have to use custom LLVM intrinsics for the enum values (analogous to unstable::atomics::AtomicOption, i guess?).

More clearly stated, the goal is to get LLVM to (a) on x86, emit just a "mov" but refuse to reorder it, and (b) on ARM, to emit an acquire barrier after the move.

[huonw]

Visiting for triage, appears to still be a problem (possibly WONTFIX because newrt will replace this code?).

[bblum]

yeah there should maybe be a metabug for the list of stuff we can close once all the old rt code is gone

[bblum]

As of #8008 we now have the corresponding acquire barrier in the new runtime pipes. (Old runtime pipes still an issue.)

[thestinger]

Removed by #8170, the bug tracking a rewrite is #7668.