Dr. Dobb's Journal July, 2004
I/O Multiplexing &
Scalable Socket Servers
Dear DDJ,
I read Ian Barile's article "I/O Multiplexing & Scalable Socket Servers" (DDJ, February 2004) with great interest, as I am currently involved in this area of work from two directions: implementing servers with similar load requirements, and refining portable C++ frameworks that implement the foundational code that Ian also implemented.
Ian and I (and many developers I have the privilege of working with) have learned similar lessons about scalable networked applications that require a large number of concurrent connections: It's hard, and the facilities for implementing them are nonuniform and very unportable. I commend Ian for his research and excellent explanation of the issues and some of the ways to solve the problems on Windows and UNIX.
For those readers who are considering writing such a server, I highly recommend Ian's article, and I also recommend learning about the Adaptive Communication Environment (ACE). ACE offers two very important frameworks upon which this type of scalable server can be built: The Reactor framework uses facilities such as select(), WaitForMultipleObjects(), and /dev/poll to effectively demultiplex I/O events; the Proactor framework uses facilities such as Windows I/O completion ports and POSIX Asynchronous I/O to offer overlapped (or, asynchronous) I/O in a portable fashion. Code that is developed using one of these frameworks can simply be recompiled for a new platform and executed, most often with no changes. This is critically important for a networked application because the facilities Ian described are not portable, and even when portable, the capabilities and limitations vary greatly between platforms.
ACE also offers an efficient message-block abstraction that's used with the Reactor and Proactor frameworks to manipulate data efficiently in such a server. There's also a Singleton implementation, and many other facilities and classes to aid development of concurrent networked applications across a wide range of platforms.
ACE is an open-source product that enjoys wide use and success. Readers can learn more about ACE at http://www .riverace.com/ and at http://www.cs.wustl.edu/~schmidt/ACE.html.
Steve Huston
shustonriverace.com
Subject: The SquareList Data Structure
Dear DDJ,
I just discovered the article "The SquareList Data Structure" by Mark Sams (DDJ, May 2003). (I'm about a year behind on my reading.) Mark's article reminded me of one I published in the 1970s: "Sequentially Encoded Data Structures that Support Bidirectional Scanning" (ISCA 1974: 188-194), which showed how to combine forward and backward pointers for two-way lists into one value using second-order differences (Honeywell owns the patents).
This means that two-way lists require no more space than one-way lists. Ex-or address encoding and parity checksums also permitted single-error detection and recovery from any single address error in the list, so the error protection value of two-way pointer redundancy is preserved.
Bob Lechner
lechnercs.uml.edu.
Gameboy Advance
Dear DDJ,
I just wanted to let you know that I got my copy of the May 2004 issue of DDJ the other day and was delighted to see the article "Gameboy Advance for Non-Gaming Applications" by Aarul Jain and Dhananjay V. Gadre. Actually, I wasn't so much interested in programming the Gameboy itself as the FPGA that comes on the Xport board. I took a class in computer architecture a year or so ago and we learned to design simple pipelined processors using Verilog. I tried the processor I built using a Verilog simulator but was never able to realize it in actual hardware. This FPGA board looks like an ideal platform for experimenting with simple hardware designs. I ordered one immediately! I'm a bit worried that 150K gates won't be enough to do what I want to do, but it's a start. Also, the GBA/Xport combination is much cheaper than the FPGA evaluation boards that are available from the FPGA vendors. Anyway, I'm about to delve into hardware design thanks to a pointer from DDJ.
David Betz
dbetzxlisper.mv.com
The Irony of Extreme Programming
Dear DDJ,
I enjoyed the article "The Irony of Extreme Programming" by Matt Stephens and Doug Rosenberg (DDJ, May 2004). The best objection to XP I've heard was by Rick Bradley: "Gradient descent isn't necessarily going to get you to a global minimum" (http://nlug.org/mail/nlug__2002_05/0489 .html). This pretty much sums up most of the problems brought out in the article.
Shawn P. Garbett
ShawneLucidSoft.net
Quit Buggin' Me
Dear DDJ,
I enjoyed Jonathan Erickson's May 2004 editorial "Quit Buggin' Me!" It reminded me of a 35-mm slide I have that shows a printed circuit board with a bug in it—quite literally. Some insect must have gotten between the layers of the fiberglass materials and got itself preserved in the epoxy sandwich. At first we couldn't believe the coincidence of finding this "bug" during a quick inspection of the prototype PCB, but there it was. A colleague at Virginia Tech took a "through-board" image for us and provided the slide.
Jon Titus
jontituscomcast.net
readTSC Optimization
Dear DDJ,
Below is what I think is a better implementation of readTSC for GCC than what Tim Kientzle presented in his article "Optimization Techniques" (DDJ, May 2004):
#define readTSC() ({ unsigned long long __scr; \
__asm__ __volatile__
("rdtsc" : "=A" (__scr)); __scr;})
This allows the compiler more latitude in assigning registers. In addition, the __volatile__ prevents the compiler from rearranging things, which could invalidate timings in some cases. I can't take credit for this myself—I got it from the Linux kernel. It does seem to work very well.
Mark Rustad
mrustadieee.org
Optimizing for Intel Architecture CPUs
Dear DDJ,
Victor Duvanenko's article "Optimizing For Intel Architecture CPUs" (DDJ, May 2004) cheered me up in unexpected ways. I was pleased to learn that a major MMX feature consisted of adding big registers together with a carry inhibit at appropriate boundaries. But it was also somehow familiar and, after a moment, I remembered the row of levers across the bottom of many early 20th-century comptometers, which do the same thing! Mostly used for subtraction, the levers also supported adding multiple columns simultaneously—for convenience, to be sure, not speed.
J.G. Owen
owen_labsworldnet.att.net
DDJ