暗行御史

접기

For many applications, threads are overkill but on some occasions they can be useful.

Let's say that you want to check the availability of many computers on a network ... you'll use ping. But there's a problem - if you "ping" a host that's not running it takes a while to timeout, so that when you check through a whole lot of systems that aren't responding - the very time a quick response is probably needed - it can take an age.

Here's a Python program that "ping"s 10 hosts in sequence.


Running that program, it works but it's a bit slow:


That was 28 seconds - in other words, an extra 3 seconds per unavailable host.


I'll write the application and test it first ... then add a few notes at the bottom.


And running:


3 seconds - much more acceptable than the 28 seconds that we got when we pinged the hosts one by one and waited on each.


We're going to run code concurrently to ping each host computer and (being Python), we create an object for each of the concurrent tests (threads) we wish to run. Each of these objects inherits from the Thread class so that we can use all of the logic already written in Python to provide our parallelism.

Although the constructor builds the thread, it does not start it; rather, it leaves the thread based object at the starting gate. The start method on the testit object actually triggers it off - internally, the start method triggers the run method of the testit class and alse returns to the calling code. In other words, this is the point at which the parallel processing actually starts, and the run method is called indirectly (via a callback, in a similar way to sort and map make callbacks).

Once parallel processes have started, you'll want some way to bring the responses back together at the end and in this first simple example, I've used a join. Note that this is NOT the same join method that you have in the string class ;-)

A join waits for a run method to terminate. So, having spawned a series of 10 pings in our example, our code waits for them to finish .... and it waits in the order that they were started. Some will be queuing up and completed long before our loop of joins gets to them, but that doesn't matter!


If you're going to be writing a threaded application, there are (broadly) two main approaches you can take. The example that I've shown above uses a separate thread to take each request through from beginning to end and all the threads have the same structure. An alternative strategy is to write a series of "worker" threads each of which performs a step in a multistep process, and have them passing data on to one another. It's the difference between having an employee to walk each order through your factory and having employees at a production line passing each job on.

Where you're running threads, you have to be very much aware of the effect they can have on one another. As soon as you have two workers, their work may interfere with one another and you get involved in synchronisation (locking) of objects to ensure that this doesn't happen.

Locking / synchronisation brings its own further complications in that you have to involve "deadlocks" where two threads both require two resources ... each grabs the first, then waits for the second which (because the other has it) never becomes available.


We've used the operating system's ping process in this example program. Ping responses vary between operating systems and you may need to alter the ping command and regular expression to match the response. The example above has been tested on Fedora Core Linux.

Threading makes heavy use of Operating System capabilities and is NOT as portable (no matter what language you're programming in) than most code


See also Learning Python

접기