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

Henry Kao via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Mar 25 09:43:36 PDT 2020

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.

  rG LLVM Github Monorepo




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);
+      // 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>

More information about the Openmp-commits mailing list