Replace spin-wait with semaphore-based backoff for epoch table exhaustion

[badrishc]

When hundreds of threads compete for epoch table entries, the previous spin-wait loop in ReserveEntry caused 100% CPU utilization due to tight spinning with Thread.Yield().

Changes:

• Add SemaphoreSlim-based wait mechanism for threads when epoch table is full
• Split ReserveEntry into fast path (TryAcquireEntry) and slow path (ReserveEntryWait)
• Fast path: probes startOffset1, startOffset2, then circles table twice - fully inlinable
• Slow path: uses try/finally with semaphore wait - marked NoInlining since kernel wait dominates cost anyway
• Release() signals one waiting thread via volatile waiterCount check (nearly zero overhead when no waiters)
• Double-check pattern in ReserveEntryWait prevents lost wakeups: increment waiterCount, re-check for slots, then wait
• SemaphoreSlim uses Monitor.Pulse internally which provides FIFO wake-up order, preventing starvation

LightEpoch Change:

We make LightEpoch keep a separate epoch table and thread allocation per instance instead of using a static thread index table. This ensure no deadlock in case we are holding one epoch (e.g. KV) while blocked on another (e.g. AOF) because the AOF epoch is guaranteed to progress as long as other AOF threads are able to find slots in their dedicated thread table.

Performance characteristics:

• No contention: unchanged - fast path acquires entry with same probing logic
• Table full: threads wait efficiently instead of burning CPU
• Release hot path: single volatile read of waiterCount when no waiters

If lock contention in SemaphoreSlim becomes a problem, a possible optimization would be a batched signaling approach, i.e., we wait for some number of entries to be released before signaling that many number of waiters.

[Copilot]

Pull request overview

This PR replaces the spin-wait mechanism in LightEpoch's epoch table entry reservation with a semaphore-based backoff system to prevent 100% CPU utilization when hundreds of threads compete for epoch table entries. Additionally, it introduces per-instance epoch tables to prevent deadlocks when one epoch is held while waiting for another.

Changes:

• Replaced tight spin-wait loops with SemaphoreSlim-based waiting when the epoch table is exhausted
• Split epoch table entry acquisition into a fast path (TryAcquireEntry) and slow path (ReserveEntryWait) for optimal performance
• Changed from a static shared thread index table to per-instance epoch tables, preventing inter-epoch deadlocks
• Renamed ReleaseIfHeld() to TrySuspend() in the IEpochAccessor interface and moved the interface to its own file
• Added benchmark tests for epoch operations and improved BenchmarkDotNet debugging support

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
libs/storage/Tsavorite/cs/src/core/Epochs/LightEpoch.cs	Core changes implementing per-instance epoch tables with InstanceIndexBuffer, semaphore-based backoff in ReserveEntryWait, and split fast/slow path acquisition logic
libs/storage/Tsavorite/cs/src/core/Epochs/IEpochAccessor.cs	New file extracting IEpochAccessor interface with renamed TrySuspend method
libs/storage/Tsavorite/cs/src/core/TsavoriteLog/TsavoriteLog.cs	Updated to use renamed TrySuspend method
libs/storage/Tsavorite/cs/benchmark/BDN-Tsavorite.Benchmark/EpochTests.cs	New benchmark tests for epoch operations (Resume/Suspend, ProtectAndDrain, BumpCurrentEpoch)
libs/storage/Tsavorite/cs/benchmark/BDN-Tsavorite.Benchmark/BenchmarkDotNetTestsApp.cs	Added DEBUG conditional compilation for DebugInProcessConfig

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.