[clang] [clang][modules][deps] Add mutex as an alternative to file lock (PR #129751)

[Jan Svoboda via cfe-commits]

================
@@ -0,0 +1,84 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "clang/Tooling/DependencyScanning/InProcessModuleCache.h"
+
+#include "clang/Serialization/InMemoryModuleCache.h"
+#include "llvm/Support/AdvisoryLock.h"
+
+#include <mutex>
+
+using namespace clang;
+using namespace tooling;
+using namespace dependencies;
+
+namespace {
+class ReaderWriterLock : public llvm::AdvisoryLock {
+  // TODO: Consider using std::atomic::{wait,notify_all} when we move to C++20.
+  std::unique_lock<std::shared_timed_mutex> OwningLock;
+
+public:
+  ReaderWriterLock(std::shared_timed_mutex &Mutex)
+      : OwningLock(Mutex, std::defer_lock) {}
+
+  Expected<bool> tryLock() override { return OwningLock.try_lock(); }
+
+  std::error_code unsafeMaybeUnlock() override {
+    // Unlocking the mutex here would trigger UB and we don't expect this to be
+    // actually called when compiling scanning modules due to the generous
+    // default timeout of 90 seconds.
+    return {};
----------------
jansvoboda11 wrote:

I think we should either implement this properly, or never allow timing out in `waitForUnlockFor()`. The latter would probably be super confusing for clients, so I'm leaning towards the former. Opinions?

https://github.com/llvm/llvm-project/pull/129751