Commit b72718d2372093d4a9931535d6847ae1dd631075
2022-02-22T16:18:45
Vulkan: Fix the data race for mUse from two threads A data race of mUse object between two threads can occur with the following sequences: 1) You use the buffer in the context, it adds into mResourceUseList 2) You release the buffer. Now it goes into mGarbageList, even though it is still in the mResourceUseList. Now this mUse object has references from two lists, the mGarbageList and mResourceUseList, and they do not use the same mutex lock. This means the race could happen and corrupt the mUse data. The same thing could happen with ImageHelper object as well. This quick fix also grabs mGrabageMutex while processing mResourceUseList. This CL creates a new garbage list to hold garbage that has not been submitted to vulkan. And this list will only accessed from submission thread and with mGarbageMutex lock held. The advantage of this is that mSharedGarbage will only have objects that already submitted, which means it is in FIFO order so that we can break out the loop as soon as we see an uncompleted garbage. This bug was exposed by MultithreadingTest.MultiContextClear/ES3_Vulkan_SwiftShader on linux-tsan-test Bug: angleproject:7045 Change-Id: I264c970579aaa53373a61ff067fa0e21eb410ae6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3482158 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Charlie Lao <cclao@google.com>