[all-commits] [llvm/llvm-project] 4e34f0: [OpenMP][FIX] Ensure exclusive access to the HDTT map

[Johannes Doerfert via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4e34f061d65e7ee45765304088a0a831a203b85b
      https://github.com/llvm/llvm-project/commit/4e34f061d65e7ee45765304088a0a831a203b85b
  Author: Johannes Doerfert <johannes at jdoerfert.de>
  Date:   2022-03-25 (Fri, 25 Mar 2022)

  Changed paths:
    A openmp/libomptarget/include/ExclusiveAccess.h
    M openmp/libomptarget/include/device.h
    M openmp/libomptarget/src/device.cpp
    M openmp/libomptarget/src/omptarget.cpp
    M openmp/libomptarget/src/private.h

  Log Message:
  -----------
  [OpenMP][FIX] Ensure exclusive access to the HDTT map

This patch solves two problems with the `HostDataToTargetMap` (HDTT
map) which caused races and crashes before:

1) Any access to the HDTT map needs to be exclusive access. This was not
   the case for the "dump table" traversals that could collide with
   updates by other threads. The new `Accessor` and `ProtectedObject`
   wrappers will ensure we have a hard time introducing similar races in
   the future. Note that we could allow multiple concurrent
   read-accesses but that feature can be added to the `Accessor` API
   later.
2) The elements of the HDTT map were `HostDataToTargetTy` objects which
   meant that they could be copied/moved/deleted as the map was changed.
   However, we sometimes kept pointers to these elements around after we
   gave up the map lock which caused potential races again. The new
   indirection through `HostDataToTargetMapKeyTy` will allows us to
   modify the map while keeping the (interesting part of the) entries
   valid. To offset potential cost we duplicate the ordering key of the
   entry which avoids an additional indirect lookup.

We should replace more objects with "protected objects" as we go.

Differential Revision: https://reviews.llvm.org/D121057