Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Multiple threads
Some examples
Send-driven (client/server)
Reply-driven (server/subserver)
An important subtlety
that we’re limited only by the number of available machines on the network (and
network bandwidth, of course). Combining this with multiple threads on a bunch of
SMP boxes distributed over a network yields “clusters of computing,” where the
central “arbitrator” delegates work (via the server/subserver model) to the SMP boxes
on the network.
Now we’ll consider a few examples of each method.
Filesystems, serial ports, consoles, and sound cards all use the client/server model. A
C language application program takes on the role of the client and sends requests to
these servers. The servers perform whatever work was specified, and reply with the
answer.
Some of these traditional “client/server” servers may in fact actually be reply-driven
(server/subserver) servers! This is because, to the ultimate client, they appear as a
standard server, even though the server itself uses server/subserver methods to get the
work done. What I mean by that is, the client still sends a message to what it thinks is
the “service providing process.” What actually happens is that the “service providing
process” simply delegates the client’s work to a different process (the subserver).
One of the more popular reply-driven programs is a fractal graphics program
distributed over the network. The master program divides the screen into several areas,
for example, 64 regions. At startup, the master program is given a list of nodes that
can participate in this activity. The master program starts up worker (subserver)
programs, one on each of the nodes, and then waits for the worker programs to send to
the master.
The master then repeatedly picks “unfilled” regions (of the 64 on screen) and delegates
the fractal computation work to the worker program on another node by replying to it.
When the worker program has completed the calculations, it sends the results back to
the master, which displays the result on the screen.
Because the worker program sent to the master, it’s now up to the master to again
reply with more work. The master continues doing this until all 64 areas on the screen
have been filled.
Because the master program is delegating work to worker programs, the master
program can’t afford to become blocked on any one program! In a traditional
send-driven approach, you’d expect the master to create a program and then send to it.
Unfortunately, the master program wouldn’t be replied to until the worker program
was done, meaning that the master program couldn’t send simultaneously to another
worker program, effectively negating the advantages of having multiple worker nodes.
April 30, 2009 Chapter 2 • Message Passing 89