<br><tt><font size=2>Okay, next silly question.  :) <br>
<br>
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: <br>
<br>
with lock: <br>
  do_critical_section_stuff_that_might_take_awhile() <br>
<br>
and then continues. <br>
<br>
Which is almost the same as: <br>
<br>
lock.acquire() <br>
try: <br>
  do_critical_section_stuff_that_might_take_awhile() <br>
finally: <br>
  lock.release() <br>
<br>
Now we discover that It Would Be Nice if some requests got priority over
others, as in something like: <br>
<br>
lock.acquire(importance=request.importance) <br>
try: <br>
  do_critical_section_stuff_that_might_take_awhile() <br>
finally: <br>
  lock.release() <br>
<br>
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). <br>
<br>
Other requirements are that the code to do this be as simple as possible,
and that it not mess anything else up.  :) <br>
<br>
My first thought was something like a new lock-ish class that would do
roughly: <br>
<br>
class PriorityLock(object): <br>
<br>
    def __init__(self): <br>
        self._lock = threading.Lock() <br>
        self._waiter_map = {}  # maps TIDs to
importance<br>
        <br>
    def acquire(self,importance=0): <br>
        this_thread = threading.currentThread() <br>
        self._waiter_map[this_thread] = importance
# I want in <br>
        while True: <br>
            self._lock.acquire() <br>
            if ( max( self._waiter_map.values())<=importance
): # we win <br>
                del self._waiter_map[this_thread]
 # not waiting anymore <br>
                return # return
with lock acquired <br>
            self._lock.release()  #
We are not most impt: release/retry<br>
            <br>
    def release(self): <br>
        self._lock.release() <br>
<br>
(Hope the mail doesn't garble that too badly.) <br>
<br>
Basically the acquire() method just immediately releases and tries again
if it finds that someone more important is waiting. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Tx, <br>
DC <br>
<br>
--- <br>
</font></tt>