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

Dmitry Vyukov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 11 00:00:13 PDT 2021


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.

We don't need to re-lock in read mode. We can lock in the strongest mode: write lock if either mo or fmo requires a release, and then do acquire under write if it turned out we need only acquire. It's fine to read a data structure under write lock.


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

https://reviews.llvm.org/D99434



More information about the llvm-commits mailing list