================
@@ -184,6 +184,101 @@ DependencyScanningFilesystemSharedCache::CacheShard::
return *CachedEntry;
}
+DependencyScanningFilesystemSharedCache::SlotAcquisitionResult
+DependencyScanningFilesystemSharedCache::CacheShard::acquireFilenameSlot(
+ StringRef Filename) {
+ assert(llvm::sys::path::is_absolute_gnu(Filename));
+ std::unique_lock<std::mutex> LockGuard(CacheLock);
+ // Cache hit.
+ if (auto It = CacheByFilename.find(Filename); It != CacheByFilename.end()) {
+ if (const auto *Entry = It->getValue().first)
+ return SlotAcquisitionResult{Entry, nullptr};
+ }
+
+ // Another worker is producing for this filename, wait for it.
+ if (auto It = InProgressByFilename.find(Filename);
+ It != InProgressByFilename.end()) {
+ std::shared_ptr<InProgressEntry> Pending = It->second;
+ Pending->CondVar.wait(LockGuard, [&] { return Pending->Done; });
----------------
artemcm wrote:
> but that must be causing a fair amount of spurious wake-ups when many threads
> concurrently use the same shard.
There shouldn't be any extra wake-ups. Each `InProgressEntry` owns its own
`condition_variable`, so `notify_all` only wakes waiters on that one key;
sharing the shard mutex doesn't spill wakeups across keys.
That said, there may still be contention on the shard lock with this mechanism
so I took the suggestion and did the refactor: the shard `CacheLock` now guards
only the maps and is released before the wait, which runs on a per-entry
mutex/CV.
I benchmarked this with a Swift dependency scan, and on a high-concurrency scan
with a warm scanner-PCM filesystem cache, wall time dropped ~4% (5.69s →
5.46s), and run-to-run variance fell quite a bit as well. Cold-cache scans were
flat with no regressions. Thanks!
https://github.com/llvm/llvm-project/pull/199680
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
