[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