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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
