Deadlock is the most infamous parallel programming pitfall, and for this reason, we will start with this one. To describe the situation, we will follow the metaphor of bureaucrats.

The bureaucrat has to stamp a paper he has in his hand. To do that, he needs the stamp, and he also needs the inkpad. First, he goes to the drawer where the stamp is and takes it. Then, he walks to the drawer where the inkpad is and takes the inkpad. He inks the stamp, pushes on the paper. Then, he puts the stamp back to its place and then the inkpad back in its place. Everything is nice, we are on cloud 9.

What happens if another bureaucrat takes the inkpad first and then the stamp second? They may soon end up as one bureaucrat with the stamp in hand waiting for the inkpad and another one with the inkpad in hand waiting for the stamps. And, they may just stay there, frozen forever, and then more and more start to wait for these locks, the papers never get stamped, and the whole system sinks into anarchy.

To avoid such situations, the locks have to be ordered and the locks should always be acquired in the order. In the preceding example, the simple agreement that the inkpad is acquired first and the stamp second solves the problem. Whoever acquired the stamp can be sure that the inkpad is free or will soon be free.