So fyi, If you really want something like this: Just use: http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock And always get a write lock. It is a slightly different way of getting those locks (via a context manager) but the implementation underneath is a deque; so fairness should be assured in FIFO order... https://github.com/harlowja/fasteners/blob/master/fasteners/lock.py#L139 and https://github.com/harlowja/fasteners/blob/master/fasteners/lock.py#L220 -Josh Chris Friesen wrote: > On 05/15/2017 03:42 PM, Clint Byrum wrote: > >> In order to implement fairness you'll need every lock request to happen >> in a FIFO queue. This is often implemented with a mutex-protected queue >> of condition variables. Since the mutex for the queue is only held while >> you append to the queue, you will always get the items from the queue >> in the order they were written to it. >> >> So you have lockers add themselves to the queue and wait on their >> condition variable, and then a thread running all the time that reads >> the queue and acts on each condition to make sure only one thread is >> activated at a time (or that one thread can just always do all the work >> if the arguments are simple enough to put in a queue). > > Do you even need the extra thread? The implementations I've seen for a > ticket lock (in C at least) usually have the unlock routine wake up the > next pending locker. > > Chris > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev