ordered threading

[Robin Becker]

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

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.
I was being naive.
>
>You could easily enough build an OrderedLock class whose acquire and release
yes I guess that's what I'll try and do
>methods implement whatever scheme you want, hiding the unordered nature of
>an internal mutex under a layer of serial-number cruft.  But then why not do
>these things serially in a single thread to begin with?
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 you have frequent rigid ordering requirements, threads are likely the
>wrong approach.
>
>> Also if blocked can a thread be killed in any way?
>
>No, not short of killing the whole program.  A thread blocked on a condition
>that will never become true is a symptom of confused application design, not
>of a weakness in the thread model <wink>.
>
>expand-the-condition-to-include-"or-i-should-die-now"-ly y'rs  - tim
>
>
>
>

-- 
Robin Becker