GPU drivers have a deadlock problem. A single GPU command buffer can reference multiple shared buffers, and those buffers can be locked in any order; the kernel driver is the one that deals with locking.
Say process A submits a batch that touches buffers in order X, then Y, and process B submits a batch touching the same two buffers in order Y, then X. Classic AB-BA deadlock situation, except now it is the kernel driver holding the bag.
To deal with this situation, a wound/wait mutex is used (an idea borrowed from the database world, not graphics).
Every task trying to lock a group of buffers first gets a reservation ticket, a monotonically increasing number from a global counter. That ticket represents the task’s transaction, and it does not change for the life of that transaction, even across retries.
When two tasks contend for the same buffer, the ticket decides who wins. This is where the two classic algorithms come in: Wait-Die and Wound-Wait.
In Wait-Die, if the lock holder is younger than you, you simply wait. If the lock holder is older than you, you back off and die, meaning you drop every lock you already hold and retry from scratch.
Wound-Wait flips the direction of the check. If the lock holder is younger than you, you wound it, marking it so it dies on its own the next time it touches a contended lock. If the lock holder is older, you wait.
Wound-Wait tends to produce fewer backoffs overall, at the cost of more expensive recovery when a backoff does happen. Both algorithms guarantee forward progress.
This is a nice example of a database concurrency control technique showing up, almost unmodified, inside a kernel subsystem built for an entirely different problem.