Figure 3-1. While serialization and queuing are related, they are distinct. Diagram A shows a classic queuing situation. Diagram B shows a serialization issue because there are idle CPUs. Diagram C is a serialization issue because there are processes queuing while there are idle CPUs.

Diagram A on the left side of Figure 3-1 is the classic queuing situation in which all the servers (think CPUs) are busy servicing transactions, and there are other processes waiting to be serviced. This represents parallelism, as all available servers are involved in processing transactions.

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.