[PATCH] D99434: [TSAN] Honor failure memory orders in AtomicCAS

[Dmitry Vyukov via Phabricator via llvm-commits]

dvyukov added a comment.

In D99434#2748778 <https://reviews.llvm.org/D99434#2748778>, @bruno wrote:

> Thank you @dvyukov for another round of reviews! A have more questions for you.
>
> Yes, fmo can be `seq_cst`. Take `mo == mo_release` and `fmo == mo_seq_cst`, we'd be acquiring the mutex with `write_lock`, which is fine under success. However, during failure, I don't see another solution besides `s->mtx.Unlock()` before honoring and calling `GetOrCreateAndLock` again to obtain the lock with `write_lock = false`. Since you said in a previous review that it would be too expensive to lock again, what do you suggest as an alternative? I wonder whether my concern is even legit (?) given that the `mo == mo_release` and `fmo == mo_seq_cst` in the testcase works regardless of this lock/unlock dance.
>
> It's also the case that the current added testcase takes ~20s on a fast linux machine, which seems way over the bar, I haven't tried to make it better yet, but (at least) diminishing the mo/fmo combinations should help, other ideas?

This is too long. But I think it's just to the "atexit sleep" in tsan. You can do this, and maybe even set atexit_sleep_ms to 0:

  test/tsan/fork_atexit.cpp:// RUN: %clangxx_tsan -O1 %s -o %t && %env_tsan_opts=atexit_sleep_ms=50 %run %t 2>&1 | FileCheck %s


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99434/new/

https://reviews.llvm.org/D99434