[Openmp-commits] [PATCH] D76780: [OpenMP] Added memory barrier to solve data race

[Henry Kao via Phabricator via Openmp-commits]

hkao13 updated this revision to Diff 252601.
hkao13 added a comment.

Added memory barrier to solve potential data race when acquiring lock for critical section.

Potential data race occurs when acquiring lock for a critical section which triggers the assertion failure (KMP_DEBUG_ASSERT(this_thr->th.th_next_waiting == 0)). This could be due to the weaker memory consistency model in ARM. Putting debug traces in the data race prone region (after thread is done spinning and acquiring the lock) makes the issue not reproducible. I add a memory barrier to ensure all threads see consistent view of shared memory (the gtid for the next thread waiting) before the failing assertion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76780

Files:
  openmp/runtime/src/kmp_lock.cpp


Index: openmp/runtime/src/kmp_lock.cpp
===================================================================
--- openmp/runtime/src/kmp_lock.cpp
+++ openmp/runtime/src/kmp_lock.cpp
@@ -1246,6 +1246,9 @@
       if (this_thr->th.th_next_waiting != 0)
         __kmp_dump_queuing_lock(this_thr, gtid, lck, *head_id_p, *tail_id_p);
 #endif
+      // Make sure all updates to thread structures are complete before
+      // assertion check.
+      KMP_MB();
       KMP_DEBUG_ASSERT(this_thr->th.th_next_waiting == 0);
       KA_TRACE(1000, ("__kmp_acquire_queuing_lock: lck:%p, T#%d exiting: after "
                       "waiting on queue\n",


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76780.252601.patch
Type: text/x-patch
Size: 638 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20200325/429d9112/attachment.bin>