Lock contention: ownership, queues and barging

Exact schedule state

Ownership is an explicit state

Each thread must execute four critical sections protected by a single lock. Only the current owner can hold the lock, and its release occurs at a recorded model tick. Other ready threads enter a waiting queue. After releasing, a thread either performs its configured outside work or becomes eligible again immediately. The diagram shows owners, waiters and completed threads, while the readable trace identifies the acquisition and release at the selected tick. Completion and throughput come from this schedule, not from browser refresh frequency or elapsed wall-clock time.

Control contention and reacquisition

Contending threads sets how many participants run the same four-operation workload. Critical-section duration fixes how long one acquisition holds the shared lock. Work outside the lock delays that thread’s next request without occupying the lock. FIFO waiting queue grants the oldest queued request. Released owner may barge lets the just-released owner reacquire ahead of existing waiters when its outside-work delay is zero; otherwise the existing queue order is used. This is a deliberately defined unfair policy, not a claim about every operating system or Java lock. Every setting rebuilds the finite schedule.

Try fairness and the serial bottleneck

Set four threads, a three-tick critical section and zero outside work. Under FIFO, the first acquisitions belong to threads zero, one, two and three. Switch to barging: thread zero can perform all four operations before another waiter acquires the lock. Both policies still complete all sixteen operations in this finite fixture, but their waiting-time distribution differs. Increase the critical section to ten ticks. With no outside work, the completion time becomes sixteen times ten ticks because this shared resource cannot execute two protected operations simultaneously. Add outside work and compare whether another waiting thread keeps the lock busy.

Inspect timing without overclaiming

Play spreads the computed schedule over sixty inspection seconds. Pause holds it, Next state advances one recorded tick, Restart rewinds, Speed changes viewing pace and Inspect time scrubs the trace. Restore defaults resets all parameters. Accumulated queue wait is updated on acquisition; a currently waiting request also has a queued-at timestamp in the inspector. Throughput is completed operations divided by elapsed model ticks and is undefined at tick zero. It is not operations per real second or a benchmark. The fixture omits lock implementation overhead, CPU preemption, priority inversion, cache effects, cancellation and an unbounded stream of new contenders. Fairness here follows the explicit selected policy, not a universal guarantee.