[Openmp-commits] [PATCH] D121058: [OpenMP][FIX] Avoid races in the handling of to be deleted mapping entries

Johannes Doerfert via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Sat Mar 5 13:51:47 PST 2022


jdoerfert created this revision.
jdoerfert added reviewers: JonChesterfield, jhuber6, tianshilei1992.
Herald added subscribers: guansong, bollu, yaxunl.
Herald added a project: All.
jdoerfert requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: OpenMP.

If we decided to delete a mapping entry we did not act on it right away
but first issued and waited for memory copies. In the meantime some
other thread might reuse the entry. While there was some logic to avoid
colliding on the actual "deletion" part, there were two races happening:

1. The data transfer back of the thread deleting the entry and the data transfer back of the thread taking over the entry raced.
2. The update to the shadow map happened regardless if the entry was actually reused by another thread which left the shadow map in a inconsistent state.

To fix both issues we will now update the shadow map and delete the
entry only if we are sure the thread is responsible for deletion, hence
no other thread took over the entry and reused it. We also wait for a
potential former data transfer from the device to finish before we issue
another one that would race with it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121058

Files:
  openmp/libomptarget/include/device.h
  openmp/libomptarget/src/device.cpp
  openmp/libomptarget/src/omptarget.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D121058.413249.patch
Type: text/x-patch
Size: 17945 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20220305/ddec14b5/attachment-0001.bin>


More information about the Openmp-commits mailing list