[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));
----------------
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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103648