In the conventional multi-threaded model, an application is divided into a collection of threads. Thread-based programs use multiple threads of control within a single address space. They achieve concurrency by suspending a thread blocked on I/O or some other event and resuming execution in a different thread. In this model, the programmer must carefully protect shared data structures with locks or mutexes. Furthermore, there is frequent need to coordinate and synchronize the progress of different threads with respect to each other. Condition variables, semaphores and other similar primitives are used for these purposes.
Of the many types of locking mechanisms available, they can be broadly classified into two types.

1. Idle-waits
2. Busy-waits

Idle-waits happen when execution is blocked and the thread switches context. This obviously comes with the context switching overhead.
Busy-waits happen when the process repeatedly checks if the condition is true. While it avoids context switching overhead, it has the extra processing overhead of continuously checking for conditions.
In addition to involuntary context switching or busy waiting overhead which is an absolute loss with no useful function, it also introduces “software lockout” and “parallel slowdown” problems. As number of concurrent processes grows in number, they spend more and more time ‘waiting’ for others to relinquish resources that they need, rather than spending time in useful work. This gives diminishing returns and after sometimes the marginal gain from adding more computational resources just reaches zero. This is an implementation problem and needs to be understood separately from the problems which are inherently averse to any parallelism.
While waiting for an I/O event to occur is a necessary waiting, we argue that blocking and waiting on semaphore queues is absolutely unnecessary.
The problem has recently taken a new dimension with the advent of Multi-Core processors. While previously all the threads ‘seemed’ to execute in parallel while in fact they executed serially on the single available processor, now threads ‘actually’ execute in parallel on different cores of the same processor.
This new dimension in parallel computing is not fully understood even today specially in context of concurrency and its related issues.
Multi-core processors have manifested an age old problem with the way code is written so far. That is in the “separation of abstractions that relate to problem, from the abstractions that relate to their execution”. Previous programming paradigms badly mixed the two concerns.