Semaphore Fairness Limits: FIFO Acquire Order Without Scheduling Guarantees

Question

Fairness as an ordering policy, not a scheduling guarantee
java.util.concurrent.Semaphore exposes a constructor that accepts a fairness boolean, and the class has offered that parameter since Java 5. Setting it to true makes threads blocked in acquire() obtain permits in FIFO order, which limits starvation among contending threads. The default, false, leaves acquisition order nondeterministic.
The unresolved part is the scope of the guarantee. Fairness constrains the order in which waiting threads are released by this semaphore; it says nothing about which thread the operating system schedules next, so a fair semaphore does not yield deterministic execution order or bounded latency. Fair mode also adds ordering bookkeeping relative to the barging-friendly default.
Questions to settle before choosing a mode

For the target JDK version, which acquisition methods are documented to honor fairness, and which are documented to bypass it?
Which workload characteristics make the ordering overhead acceptable relative to the starvation risk it removes?
How should a test distinguish FIFO acquisition order from ordinary scheduling variance across repeated runs?

Tasadduq Burney · Answer

Answering the Core Questions

Which acquisition methods honor fairness?
    
      Blocking calls that can be queued: acquire(), acquire(int permits), acquireUninterruptibly(), acquireUninterruptibly(int permits), acquire(long timeout, TimeUnit unit), acquire(int permits, long timeout, TimeUnit unit). These methods consult the semaphore’s internal FIFO queue when fair is true.
      Non‑blocking or “try” variants: tryAcquire(), tryAcquire(int permits), tryAcquire(long timeout, TimeUnit unit) do not respect fairness; they return immediately based on the current permit count.
      Internally, the semaphore’s doAcquire routine performs the fairness check; any method that ultimately calls doAcquire is subject to the flag.

When is the FIFO overhead worth it?
    
      High contention with a small number of permits (e.g., a fixed thread pool or a rate‑limited resource).
      Long‑running or blocking operations where a single thread must not starve while others finish quickly.
      Security or policy scenarios that require predictable turn‑taking (e.g., per‑user quota enforcement).
      Situations where a deterministic acquisition order simplifies debugging or audit logging.

How to test FIFO acquisition vs OS scheduling?
    
      Instantiate a fair semaphore: Semaphore sem = new Semaphore(1, true);
      Use a CountDownLatch to start all worker threads simultaneously.
      Each thread records its own ID and the order in which it successfully calls acquire() into a thread‑safe list.
      After all threads finish, sort the list by the recorded acquisition timestamps and compare it to the arrival order in the semaphore’s queue (which can be inspected via a debugging tool or by extending the semaphore class for testing).
      If the recorded order matches the queue order, fairness is upheld; any deviation indicates that the OS scheduler reordered the threads after they were released from the semaphore.

Why Fairness Doesn’t Guarantee Execution Order
Even with fair = true, the semaphore only guarantees that permits are handed out in FIFO order. Once a thread receives a permit, it becomes a runnable task in the JVM’s thread pool, and the underlying OS scheduler decides when it actually runs. Therefore:

Execution latency can still vary wildly across runs.
  Deterministic ordering of run() invocations is not achieved.
  Fairness is a starvation‑prevention measure, not a real‑time guarantee.

Practical Recommendation

Use a fair semaphore only when you need to avoid starvation in high‑contention, bounded‑resource scenarios.
  Measure throughput impact in your specific workload; a 5–10 % hit is common but acceptable for many server applications.
  Keep non‑fair semaphores for throughput‑critical paths where occasional starvation is tolerable.
  When testing, log acquisition order and compare it to the semaphore’s queue to confirm fairness is active.

Missing Diagnostic Detail
To tailor the recommendation precisely, could you confirm which Java Development Kit (JDK) version you are targeting? The documented behavior of fairness‑sensitive methods can vary subtly between JDK 8, 11, 17, and 21.

Semaphore Fairness Limits: FIFO Acquire Order Without Scheduling Guarantees

Fairness as an ordering policy, not a scheduling guarantee

Questions to settle before choosing a mode

1 answer

Answering the Core Questions

Why Fairness Doesn’t Guarantee Execution Order

Practical Recommendation

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments