aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Writer/BitcodeWriterPass.cpp
diff options
context:
space:
mode:
authorJohannes Doerfert <johannes@jdoerfert.de>2022-03-02 13:46:01 -0600
committerJohannes Doerfert <johannes@jdoerfert.de>2022-03-28 22:33:18 -0500
commitb316126887d0e41a9e22717419d43af9d81b764c (patch)
treef5a237315f9426590ea4f435f5570b61675135bf /llvm/lib/Bitcode/Writer/BitcodeWriterPass.cpp
parentba93e4e33ead8aaa20e762211facaf3fa7e1439f (diff)
downloadllvm-b316126887d0e41a9e22717419d43af9d81b764c.zip
llvm-b316126887d0e41a9e22717419d43af9d81b764c.tar.gz
llvm-b316126887d0e41a9e22717419d43af9d81b764c.tar.bz2
[OpenMP][FIX] Avoid races in the handling of to be deleted mapping entries
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. Fixes https://github.com/llvm/llvm-project/issues/54216 Differential Revision: https://reviews.llvm.org/D121058
Diffstat (limited to 'llvm/lib/Bitcode/Writer/BitcodeWriterPass.cpp')
0 files changed, 0 insertions, 0 deletions