ordered threading

[Robin Becker]

From: Robin Becker <robin at jessikat.demon.co.uk>

In message <1281033720-53905059 at hypernet.com>, Gordon McMillan
<gmcm at hypernet.com> writes
>Robin Becker writes:
>
>> In article <000a01bec583$30332b40$769e2299 at tim>, Tim Peters
>> <tim_one at email.msn.com> writes
>
>> >[Robin Becker]
>> >> I have an unbounded number of worker threads which occasionally require
>> >> access to a unique server thread. I can easily mutex access to the
>> >> server thread, but is there any obvious/easy way to ensure that the
>> >> blocked workers wake up in the right order?
>> >
>> >No threading system on earth allows specifying the order in which blocked
>> >threads will wake up, although some systems (not Python's) allow you to
>> >*influence* the order via assorted "priority" gimmicks.
>
>> the workers are HTTP requests in separate threads from Zope I guess.
>> I want to serialise access to the time/space hog. I guess it could
>> run uniquely in the worker threads ie the locked resource would be
>> access to the hog code. I'm not sure that would let me guarantee
>> unlocking as there are ways for the worker threads to suicide.
>
>If that's what you want, you don't really need to order the 
>unblocking. Just give each thread an input queue protected by a 
>Condition. Worker threads put requests on the Hog thread's input 
>queue (including a ref to the return queue). If you find that some 
>worker threads seem to get better access to the Hog's queue than 
>others, a time.sleep(0.001) will probably fix it - since it will 
>pretty much force a context switch.
>
>
>- Gordon
thanks; I knew already that this could work. I didn't know how to force
equalisation.
-- 
Robin Becker