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

[Andrey Churbanov via Phabricator via Openmp-commits]

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.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103648