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

[Roger Ferrer Ibanez via Phabricator via Openmp-commits]

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));
----------------
AndreyChurbanov wrote:
> 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.
> 
Hi Andrey,

apologies I forgot to mention that in the comment above

`env/kmp_set_dispatch_buf.c` was easy to cause a deadlock with `KMP_DISP_NUM_BUFFERS=3` and `-DMY_SCHEDULE=guided`.

Kind regards,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103648