Proposal: Explore a CAS fast path for Semaphore with native atomics

Would you be open to a CAS fast path for Concurrent::Semaphore on CRuby with the existing C extension?

The current MutexSemaphore takes a mutex for every acquisition and release, even when permits are available. Using AtomicFixnum#compare_and_set could reduce this overhead.

Related design in Java

OpenJDK's Semaphore uses CAS to update permits, with AbstractQueuedSynchronizer handling queuing and blocking when acquisition cannot succeed. This provides a design precedent; performance on CRuby still needs its own evaluation.

Proposed approach

Use CAS when permits can be acquired immediately, and a mutex and condition variable when waiting is necessary. Enable this with the existing CRuby C extension, retaining the current implementations elsewhere. Preserve existing Ruby behavior, including large permit counts through a mutex-protected Integer fallback.

A prototype PR in my fork contains the implementation and tests; no new C code or runtime dependency is required.

Initial measurements

Apple M5 MacBook Pro, macOS 26.2, CRuby 4.0.2, YJIT disabled, CAtomicFixnum. The measured prototype was compared with the unchanged Mutex implementation. Results are median throughput over 7 samples after warmup, in millions of acquire/release pairs per second. Both implementations ran in the same process with alternating sample order.

The waiting case was slower in this run and varied substantially; these results do not establish a waiting-path improvement. The prototype also changes waiter bookkeeping and notification behavior, so the gain cannot be attributed to CAS alone. Full samples and reproduction commands are in the fork PR.

Would this direction be of interest? I would appreciate feedback on the approach and any additional validation needed before preparing an upstream PR.

Start with lib/concurrent-ruby/concurrent/atomic/mutex_semaphore.rb and inspect the existing CRuby C extension, then review the linked prototype PR and measured commit. Compare the prototype's acquire/release and waiting behavior with the current implementation, and use its tests and reproduction commands to determine what validation is still needed.