uWSGI thunder lock contention latency when worker count exceeds CPU cores

Context

uWSGI serializes accept() calls across workers using a thunder lock (system semaphore on Linux, pthread mutex elsewhere). The lock is enabled by default and prevents the thundering herd problem, but introduces contention when many workers compete for the same lock.

Goal

Understand how much the thunder lock contributes to request latency percentiles under sustained concurrent load when the configured worker count exceeds the available CPU cores.

Constraints and uncertainty

The lock_wait metric exposed via the stats server shows aggregate wait time, but its relationship to end-to-end latency percentiles (p50, p95, p99) is not documented. Disabling the lock with --thunder-lock=false trades serialization for repeated wake-ups of all idle workers, which may increase CPU usage and scheduler pressure. The optimal choice appears workload-dependent and may also vary with kernel version and async worker types (gevent, eventlet) that yield during accept.

Questions

1. What methodology reliably isolates thunder lock wait time from other latency components in a production-like workload?
2. Are there documented thresholds or heuristics for when disabling the thunder lock reduces tail latency versus when it increases CPU contention?
3. How does the contention profile differ between sync workers and async workers (gevent, eventlet) under the same concurrent load?