Diagram B in Figure 3-1 is a very common but unfortunate situation. In this case, there is a single process running on single server (think CPU), while the other three servers remain idle. This is the situation that causes some initial debate in my classes. Some may feel this is not a problem because, "That's just the way it is." But others may feel that it's a problem because the user associated with the running transaction is waiting, even though resources are available. While it is true this may just be "the way it is"-the best our technology allows-it is also true that parallelism is lacking, resulting in a serial process. As I'll explain in the next section, a tremendous amount of effort and expense go into reducing the chances of the diagram B situation occurring.

Diagram C in Figure 3-1 is extremely unfortunate and will likely be reported to the operating system vendor. It does happen, although rarely. In this situation, for some reason, the next process waiting in the queue cannot be assigned to either of the idle servers (think CPUs). There is a serialization issue, and parallelism is being thwarted.

While technical people don't usually think of it this way, it's an interesting human characteristic to desire parallelization. Anyone driving on a busy road instinctively knows that adding lanes will speed up traffic. Most people are not aware of it, but such a solution increases parallelism-allowing more work to be done in a given period of time.