[PATCH] D99434: [TSAN] Honor acquire failure mode on AtomicCAS

Bruno Cardoso Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 3 15:08:38 PDT 2021


bruno added inline comments.


================
Comment at: compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cpp:413
     TraceAddEvent(thr, thr->fast_state, EventTypeMop, 0);
     if (IsAcqRelOrder(mo))
       AcquireReleaseImpl(thr, pc, &s->clock);
----------------
dvyukov wrote:
> I think it's better to avoid doing this if the CAS will fail and fmo == mo_relaxed. It will provide more precise race detection.
> I think we could do something along the following lines:
>  - if either mo or fmo != relaxed, do GetOrCreateAndLock
>  - if either mo or fmo involves release, do a write lock
>  - evaluate cas
>  - respect mo or fmo based on the cas result
Sounds good, minor correction on the fact that fmo cannot be release.


================
Comment at: compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cpp:438
+  // those are used.
+  if (IsAcquireOrder(fmo) && s) {
+    AcquireImpl(thr, pc, &s->clock);
----------------
dvyukov wrote:
> We did not create/obtain the sync object if mo == mo_relaxed. Is mo == mo_relaxed and fmo == mo_acquire possible? If yes, then we will fail to respect fmo.
Right, will fix.


================
Comment at: compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cpp:440
+    AcquireImpl(thr, pc, &s->clock);
+    s->mtx.ReadUnlock();
+  }
----------------
dvyukov wrote:
> We used a different condition to decide if we need to do read lock. Can't this deadlock? I think we need to check write_lock.
Yea, somehow it slipped, thanks!


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

https://reviews.llvm.org/D99434



More information about the llvm-commits mailing list