Add random failures to compare_exchange_weak

[thomcc]

In practice this is pretty useful for detecting bugs.

This fails more frequently than realistic (50% (now 80%, controlled by a flag) of the time). I couldn't find any existing code that tries to model this (tsan, cdschecker, etc all seem to have TODOs there). Relacy models it with a 25% or 50% failure chance depending on some settings.

CC @JCTyblaidd who wrote the code this modifies initially, and seems interested in this subject.

[thomcc]

Unsure if the CI error here is related to me... I'll rebase and hope it fixes itself. All good now.

[thomcc]

I got a comment elsewhere about it being unfortunate that this triggers even if no other atomic operations are happening that involve the atomic variable. For future reference, and for anybody else with the same concern:

That is realistic, because on (some/most) real hardware these failures are triggered by operations by another thread on the same cache line (which might not even be part of the same allocation, let alone the same atomic). Also, all the descriptions of this in specifications I found put no bounds on when these are allowed to fail, just that they are allowed to fail randomly.

The one caveat here is that under -Zmiri-compare-exchange-weak-failure-rate=1.0 (e.g. explicitly requesting a 100% failure rate) it will fail every time, which I believe is against what's requested by most specs. That said, even this may be useful if testing a code path that tries to do something like backoff and use another algorithm under heavy contention, or whatever, so that seems fine given that it's an explicit request for the behavior.

[thomcc]

Just to check, this isn't waiting on anything from me right?

[oli-obk]

Nope, I just forgot about it. Thanks for the PR and the reminder!

@bors r+

[bors]

📌 Commit d310620 has been approved by oli-obk

[bors]

⌛ Testing commit d310620 with merge a0485c5...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing a0485c5 to master...