This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][libomptarget] Add mutex to safely read/modify HostPinnedAllocs map
AbandonedPublic

Authored by kevinsala on Sep 10 2022, 6:56 PM.

Details

Summary

The access to the HostPinnedAllocs map should be protected since different threads may be allocating and deallocating data concurrently. A thread allocating data may need to modify the map, so no other thread should access (even reading) the map at that point.

Diff Detail

Event Timeline

kevinsala created this revision.Sep 10 2022, 6:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 10 2022, 6:56 PM
kevinsala requested review of this revision.Sep 10 2022, 6:56 PM

I have a review up that removes this map entirely, for this and other reasons D133053. The review seemed to have stalled as @tianshilei1992 had concerns about changing the interface and what that meant for backwards compatibility.

I have a review up that removes this map entirely, for this and other reasons D133053. The review seemed to have stalled as @tianshilei1992 had concerns about changing the interface and what that meant for backwards compatibility.

Yeah, we still didn't make the consensus we need.

I have a review up that removes this map entirely, for this and other reasons D133053. The review seemed to have stalled as @tianshilei1992 had concerns about changing the interface and what that meant for backwards compatibility.

Yeah, we still didn't make the consensus we need.

There was a user-visible change where omp_target_free didn't work anymore for the special allocation types, but that was against the standard anyway. Then there was the plugin change. The issue was changing the plugin interface right? I could still just introduce a new one that is called by the old one, but if we remove backwards compatibility it would be much easier all around.

Is this solving an immediate error you're experiencing? If not we should wait for a consensus on removing this map entirely, otherwise if it's urgent we could probably land this temporarily.

Is this solving an immediate error you're experiencing? If not we should wait for a consensus on removing this map entirely, otherwise if it's urgent we could probably land this temporarily.

No, actually I didn't experience any error related to it. I was debugging something else and saw this concurrent access not being protected. Thus, it's not a problem to wait for a consensus on removing the map.

Is this solving an immediate error you're experiencing? If not we should wait for a consensus on removing this map entirely, otherwise if it's urgent we could probably land this temporarily.

No, actually I didn't experience any error related to it. I was debugging something else and saw this concurrent access not being protected. Thus, it's not a problem to wait for a consensus on removing the map.

I landed D133655 which removes this map entirely, thanks for the patch regardless.

kevinsala abandoned this revision.Sep 14 2022, 11:23 AM

Great! Then I'm closing this review. Thanks @jhuber6