[Openmp-commits] [PATCH] D103648: [OpenMP] libomp: fix dynamic loop dispatcher

Roger Ferrer Ibanez via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri Aug 13 03:48:13 PDT 2021

rogfer01 added inline comments.

Comment at: openmp/runtime/src/kmp_dispatch.cpp:911
+                     gtid, my_buffer_index, sh->buffer_index));
+      __kmp_wait<kmp_uint32>(&sh->buffer_index, my_buffer_index,
+                             __kmp_eq<kmp_uint32> USE_ITT_BUILD_ARG(NULL));
Sometimes (not always, so it seems a data race) running this test in an Arm 64-bit machine  with 46 cores (and in a Power9 machine with 40 cores) all the threads end waiting here, so the test doesn't progress anymore.

All the cases I've seen happen with `KMP_DISP_NUM_BUFFERS=3` and `-DMY_SCHEDULE=guided`.

Any idea how I could debug this further? 

A quick look about `sh->buffer_index` shows it is a `volatile` and it is updated in

sh->buffer_index += __kmp_dispatch_num_buffers;
KD_TRACE(100, ("__kmp_dispatch_next: T#%d change buffer_index:%d\n",
               gtid, sh->buffer_index));

KMP_MB(); /* Flush all pending memory write invalidates.  */

Given that this is not an atomic operation (yet it goes followed by a memory barrier) my only hypothesis is that the original load of `sh->buffer_index` might have read an old value but that would suggest `KMP_MB()` is not effective in these targets? So I am at loss here.


  rG LLVM Github Monorepo



More information about the Openmp-commits mailing list