Ticket locks also seem more fair than the test and set based ones since, assuming the lock is being unlocked properly, we can guarantee that a lock call will eventually return in a bounded amount of time.

Is a system of 'ticket' locking effective if different threads competing for a lock have different priorities? Would the system just have to rely on priority donation if a high-priority thread tried to take a lock held by a lower-priority thread that was swapped off the CPU?

@trip I think in your case, if there's no preemption or priority donation, there might be a priority inversion and may cause a deadlock.

In that case, because we're using locks, all of these threads must be from the same program to share an address space. Therefore, it's probably fair game to assume that the programmer needs to deal with that themselves, right?

It seems like the ticket system would also help solve the problem of non uniform memory between processors because even a processor that sees the unlocked last, if it has the ticket it can take the lock.