Dr. Dobb's Journal - December 2008 - (Page 42)

d12babk_p4db 10/10/08 10:53 AM Page 42 State of the Art by Sergey Babkin File Descriptors And Multithreaded Programs Putting the “rev” back in “revocation” When writing multithreaded programs that work with sockets, a common pattern is to have Sergey is a senior developer for Aleri. He can be contacted at babkin @verizon.net. two threads per socket—one thread writes the data to the socket, another one reads the data. Obviously, the socket library used for this should be threadsafe to start with and support a read from a socket in one thread and a write to the socket in the other thread without corrupting the library’s socket state. The raw system calls read() and write() support this. Your experience with the more sophisticated libraries may vary. The write thread may be implicit: It may be just a mutex that allows any thread to write into a socket without interference from other threads. But reading is different. It’s asynchronous, with data supplied by the other side. It’s impossible to predict when the data will come in. Even if the remote side never sends any data, having a reading thread is still useful to detect a dropped connection. Otherwise, if only the return codes of writing are checked, the connection drop won’t be detected until the next write, and that might be a while. It might never be detected if the application has no new data to send to the socket. Such sloppy implementations are surprisingly common—you can identify these applications by lots of half-closed sockets sitting around in the operating system. This approach is not limited to sockets. It’s just as applicable to named pipes, serial ports, or any other communication with an independent source of data. For sockets there is also a variation when a thread is listening for incoming connections, and for all practical purposes, it can also be considered a reading thread, with no writing thread. All of this works well as long as the remote side cooperates nicely. But sometimes there are emergencies. Sometimes the application needs to just drop the connection and be done with it. Maybe the application was requested to exit, and now it needs to drop all the clients. Maybe just a subsystem of the application needs to be shut down. Or perhaps a single client has violated the protocol and its connection has to be dropped. This means that this reading thread must be stopped. How? Turns out, the answer is not that simple. Even as the widespread libraries go, lots and lots of them get it wrong. I’m going to describe how to get it at least reasonably right and how to fix it in the existing libraries. The first obvious option is by using a kill thread call. But many thread libraries don’t support this call, and the libraries supporting it often advise against 42 Dr. Dobb’s Journal l www.ddj.com l December 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - December 2008

Dr. Dobb's Journal - December 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Conversations The Man Who Sold the Sky Performance on Rails LINQ-to-SQL and T-SQL A Remote Java RMI Registry Beyond B-Trees File Descriptors and Multithreaded Programs Effective Concurrency The Agile Edge Swaine's Flames

Dr. Dobb's Journal - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.