threads or queue for this task
James J. Besemer
jb at cascade-sys.com
Sat Sep 14 10:09:34 CEST 2002
robin at execulink.com wrote:
>I wish to have a server continually cycle (until interrupted by
>keyboard, signal, or whatever). It needs to perform several (say 6)
>different tasks, each of which may take significantly different
>lengths of time to perform.
I can think of two approaches that may solve your problem.
It sounds like you have a single stream of input requests which you wish
to distribute among multiple service threads.
One way is to have your main thread read the input stream, parse the
incoming commands and then launch a separate thread to handle each
incoming request. It would NOT wait for the threads to complete or
otherwise try to regulate the number of threads. Plus side is maximum
parallelism. Down-side is if commands come too fast you may exceed the
maximum thread count and the app will fail.
Another alternative is to launch a single thread for each of your
service routines. Also create a Queue for each thread and have the
threads each read commands from their respective queue. Service threads
would loop forever, reading and executing commands. Main program reads
input as before and feeds commands to the appropriate thread VIA each
threads' respective queue. Again, the main thread does NOT wait for any
threads to complete. Thus it will service requests as fast as possible
using exactly N helper threads. The degree of parallelism 0..N would
depend on the input commands arrival rates.
If this is unacceptable -- if you need to enforce some ordering on the
execution of commands, then things get a lot more complicated. E.g., if
you want to dispatch N commands, one to each helper thread, and then
wait for them all to complete before doing anything else -- you need to
consult the "threading" module (the one following "thread" in the
library ref). If it's truly that simple (read N and then execute N in
parallel) your main program could enforce this discipline, adding a
threading.Semaphore() object to synchronize on the completion of all N
threads. Threading includes various synchronization functions that
allow you to do this and more. E.g., you also could do things like
maintain a maximum of M[i] parallel instances of thread i (more than 1
but a different limit for each command).
If the threads themselves access common data structures then you need to
synchronize their access so they don't garble the results. The thread
module itself has a locking mechanism that's sufficient for implementing
regions of mutual exclusion.
If you're new to concurrent programming then you may need to consult
some books on the subject, as it's a bit tricky.
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
More information about the Python-list