Does sem_getvalue return consistent state for semaphores under concurrent access

Direct answer

No. sem_getvalue does not return consistent semaphore state under concurrent access. It returns a point-in-time snapshot, and concurrent sem_wait or sem_post calls can change the semaphore before your code acts on the value. Use it only for approximate monitoring or logging, never for admission control or flow control.

Confirmed facts

• POSIX.1-2017 specifies that sem_getvalue(sem, sval) stores the current value in *sval without altering the semaphore.
• The standard does not require that read to be atomic with respect to concurrent sem_wait or sem_post.
• The value can transition from positive to zero, or from zero to positive, between the sem_getvalue call and the next semaphore operation in the calling thread.
• Multiple threads calling sem_getvalue concurrently are unlikely to corrupt the semaphore, but each returned value is stale for control decisions.

Implementation-defined behavior to verify

• Whether blocked waiters are counted, and whether a blocked waiter forces the reported value to zero.
• Whether negative values are reported and what they signify.
• Behavior differences between unnamed, named, and process-shared semaphores.

Treat sign and magnitude as platform-specific. Check the target system's sem_getvalue man page before porting code that inspects them.

Steps for this case

1. Replace any pattern that reads sem_getvalue, tests the result, then calls sem_wait, with a single sem_trywait call. The trywait performs the check and acquisition atomically.
2. Use sem_wait and sem_post for signaling; do not poll the semaphore value to decide whether to proceed.
3. Restrict sem_getvalue to monitoring, telemetry, or debug output where staleness is acceptable.
4. If threads need to observe shared state reliably, guard that state with a mutex and condition variable instead of inspecting the semaphore count.

Verification

Run a test in which some threads alternate sem_post and sem_wait while others repeatedly call sem_getvalue. Immediately after each read, attempt sem_trywait. Record cases where a positive read is followed by trywait failure, or a zero read is followed by trywait success. Either outcome confirms the race. Then consult your platform's semaphore documentation for negative-value and waiter semantics.