Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Threads: In a Nutshell Example 1: GUI Example 2: Sockets Example 3: Pipeline Stages

Example 2: Sockets

Another classic example of event-driven code is client-server communications. A server listens for incoming connection requests; as each connection arrives, the server has to accept it and then process inbound and outbound traffic on that connection until the connection is closed by one side or the other. At any given time, the server has to be able to deal with multiple active connections from different clients, each at a different stage in its processing.

As with the previous GUI example, we have the option of handling the work synchronously or asynchronously. The synchronous code looks something like this in a classic socket-oriented API. The methods are spelled a little differently in POSIX, Java, and other environments, but all follow the basic operation.

// Example 2: Doing it all on one thread/process
// (pseudocode, and assumes select returns single events)
//
while( /*... */ ) {
   select( our socket list ); // blocks until something is ready
   if( a connection request came in )
      accept() and add it into to our socket list
   else if( a connection closed )
      close() and remove it from our socket list
   else if( one of our read sockets is ready )
                           // synchronous processing
      read more data from that socket and process it
   else if( one of our write sockets is ready )
                           // synchronous processing
   write the next chunk of data to that socket
}

A key problem with this is that all the work is being handled by a single thread. For one thing, that tends to make the code more complex; one thread has to do it all, so all the code to handle all the different kinds of clients appears in one place. For another, running all the work on one thread means that all the work will run sequentially on one core (or, equivalently, one core at a time if the operating system migrates the thread from core to core). If the total work saturates the core, then additional work will be throttled and slow down the server's responsiveness for all clients as later requests queue up and wait for earlier work to complete.

A common solution is to use Option 2: Let the server service connectionscsimultaneously by launching a new thread to handle each incoming client. Here's the basic logic:

// Applying Option 2 (pseudocode)
// Listener thread: Only accepts connections
// and launches new threads to deal with them
//

while( /**/ ) {
   wait for connection request
   accept()
   ... = new Thread( [] { HandleIt( theConnection) ); } );
}
// Each handler thread
//
void HandleIt( ... ) {
   while( wait for event on this connection ) {
                       // this could block
      if( this connection was closed ) {
        close()
        return;
      }
      else if( incoming data ready to read )
                    // synchronous processing
        read more data from this connection and process it
      else if( connection is ready to write )
                   // synchronous processing
        write the next chunk of data to this connection
}

This code is both clearer and potentially faster. The program is clearer because the code to handle each kind of client is nicely wrapped up in its own method or class, instead of being intermingled. The program is faster because it keeps different connections asynchronous and independent, so that the work on one connection doesn't have to wait to be processed sequentially behind work on another connection. This gives better responsiveness even on a single-core server that isn't heavily loaded, and it delivers better scalability under load on servers that do have parallel hardware.

Previous Page | 1 Threads: In a Nutshell | 2 Example 1: GUI | 3 Example 2: Sockets | 4 Example 3: Pipeline Stages Next Page

RELATED ARTICLES Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance SEI, Army Team Up on Software Testing Highly Scalable Parallel Sorting		TOP 5 ARTICLES No Top Articles.