Okay, next silly question. :)
We have a very simple multi-threaded system where a request comes in,
starts running in a thread, and then (zero, one, or two times per request)
gets to a serialization point, where the code does:
with lock:
do_critical_section_stuff_that_might_take_awhile()
and then continues.
Which is almost the same as:
lock.acquire()
try:
do_critical_section_stuff_that_might_take_awhile()
finally:
lock.release()
Now we discover that It Would Be Nice if some requests got priority over
others, as in something like:
lock.acquire(importance=request.importance)
try:
do_critical_section_stuff_that_might_take_awhile()
finally:
lock.release()
and when lock.release() occurs, the next thread that gets to run is one of
the most important ones currently waiting in acquire() (that's the
exciting new thing).
Other requirements are that the code to do this be as simple as possible,
and that it not mess anything else up. :)
My first thought was something like a new lock-ish class that would do
roughly:
class PriorityLock(object):
def __init__(self):
self._lock = threading.Lock()
self._waiter_map = {} # maps TIDs to importance
def acquire(self,importance=0):
this_thread = threading.currentThread()
self._waiter_map[this_thread] = importance # I want in
while True:
self._lock.acquire()
if ( max( self._waiter_map.values())<=importance ): # we win
del self._waiter_map[this_thread] # not waiting anymore
return # return with lock acquired
self._lock.release() # We are not most impt: release/retry
def release(self):
self._lock.release()
(Hope the mail doesn't garble that too badly.)
Basically the acquire() method just immediately releases and tries again
if it finds that someone more important is waiting.
I think this is semantically correct, as long as the underlying lock
implementation doesn't have starvation issues, and it's nice and simple,
but on the other hand it looks eyerollingly inefficient.
Seeking any thoughts on other/better ways to do this, or whether the
inefficiency will be too eyerolling if we get say one request per second
with an average service time a bit under a second but maximum service time
well over a second, and most of them are importance zero, but every (many)
seconds there will be one or two with higher importance.
Tx,
DC
---
--
http://mail.python.org/mailman/listinfo/python-list
