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

Andrey Churbanov via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri Aug 13 06:01:45 PDT 2021

AndreyChurbanov 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));
rogfer01 wrote:
> 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.
> Thanks!
Which test(s) you see hanging?

There indeed may be a data race somewhere in the code, I will try to take a look.  Still better to know the exact test case.

  rG LLVM Github Monorepo



More information about the Openmp-commits mailing list