One of the key reasons that multithreading is powerful and makes a big impact performance-wise is that it lends itself to the notion of parallelism or concurrency; from what we learned in the previous Chapter 14, Multithreading with Pthreads Part I - Essentials, we understand that multiple threads of a process can (and indeed do) execute in parallel. On large multicore systems (multicore is pretty much the norm now, even in embedded systems), the effect is magnified.

However, as experience teaches us, there's always a trade-off. With parallelism comes the ugly potential for races and the subsequent defects. Not only that, situations like this typically become extremely hard to debug, and therefore, fix. 

In this chapter, we shall attempt to:

• Make the reader aware as to where and what exactly these concurrency (race) defects are
• How to avoid them with good design and coding practices in multithreaded applications

Again, this chapter divides itself into two broad areas:

• In the first part, we clearly explain the problem(s), such as how atomicity matters and deadlock issues.
• in the latter part of this chapter, we present the locking (and other) mechanisms that the pthreads API set makes available to the application developer to help tackle and avoid these issues altogether.