When multi-core processors were released in the mid-2000s, developers had to face a new programming paradigm: multi-threading. For sure, SMP (Symmetric Multiprocessing) was already there since years but such machines were dedicated to particular applications.

This new processor design had some side effects: since applications were no longer executed on a single processor and developers had to synchronize shared data and avoid what we call race condition. Interestingly,  most of the time, a race condition will crash the application. When multi-core processors were introduced, many popular applications had such issues (see this discussion for iTunes) - mostly because developers did not design an application with synchronization constraints in mind. Of course, now, this design constraints is understood by most developers.

During a current project, I am investigating the common software vulnerabilities/weaknesses and their evolution over time. Among the most popular, the "race condition" issue. There is the picture.

number of issues related to synchronization issues

If we look closely, there was very few reports until multi-core were introduced. It continues to increase until 2012 (why it decreases in 2011 is still unknown) and then start to decrease. Interestingly, there are still a lot of issues related to synchronization today.

The take away from this data? Change takes time. A. Lot. It took almost 10 years for software developers to address the matter and stop writing buggy code. And there are still a lot of reported issues. Developers had to take this new constraint into account while they were not familiar with this paradigm. Teachers had to explain this issue and address the matters in class.

Change takes time and it is very difficult to predict the impact of a change - I assume nobody assumed that it would take so long for the industry to adapt to this new constraint.