threads or queue for this task

[James J. Besemer]

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.

Regards

--jb


-- 
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
				http://cascade-sys.com