Use Interlocked.Add to apply a relative delta to m_currentCount rather
than writing back an absolute snapshot-derived value, so concurrent
lock-free decrements from the WaitAsync fast path are not overwritten.

Replace plain --m_currentCount with a CAS loop to prevent a double grant
when the lock-free WaitAsync fast path decrements m_currentCount between
the > 0 check and the decrement in the slow path.

WaitCore is safe because m_waitCount++ on lock entry blocks the CAS guard
for its entire critical section. WaitAsyncCore has no such protection.

Apply the same CAS-loop pattern to WaitCore's m_currentCount decrement
that was applied to WaitAsyncCore in the previous commit. A fast-path
thread that read m_waitCount = 0 before WaitCore's m_waitCount++ can
still race with WaitCore's check-at-404 / decrement-at-407 sequence.
The CAS loop serializes both operations on m_currentCount atomically.

… stress test

The assert !waitSuccessful || m_currentCount > 0 in WaitCore could fire
spuriously in Debug builds: the lock-free WaitAsync fast path runs outside
the lock, so it can decrement m_currentCount to 0 between
WaitUntilCountOrTimeout returning and the assert executing.

Adds a stress test that races AvailableWaitHandle lazy initialization
against WaitAsync fast-path acquires and verifies the handle is never
signaled when CurrentCount == 0.

…t WaitAsync fast path

…phoreSlim

Also fix CS0420 in Release(): Volatile.Read(ref volatile_field) triggers a
compiler error in the coreclr project build; replaced with a plain field read
(already volatile) so the testhost can be rebuilt with the fixed implementation.

…ed SemaphoreSlim

…cessor task is always cancelled

- Extract duplicated CAS-decrement loop into TryDecrementCount() with
  AggressiveInlining, replacing inline copies in WaitCore and WaitAsyncCore
- Strengthen Assert.InRange to Assert.Equal in NeverUnderflows test
- Add bulk Release(2) concurrent stress test for Interlocked.Add delta math
- Add cancellation-during-fast-path stress test for count integrity
- Use m_currentCount (post-Add) instead of netCount for m_waitHandle.Set()
- Add UncontendedSync and MixedSyncAsync benchmarks for sync path coverage

Prevents the background task from pegging a CPU core in CI while still
exercising concurrent lazy initialization of the wait handle.

… file

WaitAsync(CancellationToken) returns Task, not Task<bool>; the prior
declaration didn't compile. Removed PerformanceTests/SemaphoreSlimBenchmarks.cs
since it had no csproj and wasn't wired into any project; runtime perf
benchmarks live in dotnet/performance, and the EgorBot inline benchmarks
posted on the PR cover the relevant scenarios.

The comment narrated what the next several lines do; the variable
name and surrounding structure already convey it.

Address review hazards in the WaitAsync CAS fast path:

- Make m_waitCount and m_asyncHead volatile. The fast path reads them without
  the lock; sync-waiter writes inside the lock must publish via
  release semantics rather than depending on the lock release that the
  fast path bypasses. Without this, ARM64 can let the fast path observe
  m_waitCount == 0 while a sync waiter is parked, stealing the slot and
  leaving the waiter blocked.

- Restructure AvailableWaitHandle init to publish-then-reflect:
  publish the handle unsignaled, full barrier, then conditionally Set
  based on the post-publish count read. Closes the race where
  ManualResetEvent allocation overlapped a fast-path CAS, leaving the
  handle Set with count == 0.

- WaitCore: loop instead of falling through with a stale waitSuccessful
  when TryDecrementCount loses to a fast-path acquirer. Fixes the case
  where Wait(Infinite) could return without owning a permit (silently
  dropped by the void overload, lying about acquisition for bool overloads).

- Release: use Interlocked.Add's return value for the MRE.Set sentinel
  so a fast-path decrement racing between the Add and the re-read
  doesn't mask the 0 -> positive transition.

- Strengthen the AvailableWaitHandle init test: allocate a fresh
  SemaphoreSlim per iteration so each iteration is a real attempt at
  the race. With a single semaphore the race only fires on the first
  AvailableWaitHandle access.

Defensive: the prior placement was correct because a thrown OCE always
short-circuits before re-entry, but moving 'oce' (and 'timedOut',
already loop-local) inside makes the freshness invariant explicit and
robust to future edits.

Original test had 8 workers each doing WaitAsync;WaitAsync;Release(2)
against 4 permits. Under contention, 4 workers could each grab one
permit then block on the second WaitAsync — no holder ever reaches
Release(2). Helix CI hit this on loaded ARM/Mono interp legs and
killed the work item at the 45-min timeout.

Split into pure consumers (WaitAsync only) and a single producer
issuing Release(2) bulk releases. Same intent — bulk Release racing
concurrent fast-path waiters — but deadlock-free by construction.

The handoff loop tracked two opposing counters (decrementing maxAsyncToRelease and incrementing asyncReleased) for the same loop progress. Use a single up-counter compared against the fixed bound instead. No behavior change.