Thank you for purchasing this book! We live in a concurrent world and concurrent programming is an increasingly valuable skill.
I still remember the Aha! moment when I understood how UNIX shell pipeline works. I fell headlong in love with Linux and the command line and tried out many combination filters (a filter is a program reading from standard input and writes to standard output) connected via pipes. I was amazed by the creativity and power brought about by the command line. I was working with concurrent programs.
Then, there was a change of project and I was thrown headlong into writing code using the multithreaded paradigm. The language was C or C++, which I loved deeply; however, to my surprise I found that it was a herculean effort to maintain a legacy code base, written in C/C++ that was multithreaded. The shared state was managed in a haphazard way and a small mistake could throw us into a debugging nightmare!
Around that time, I came to know about object oriented (OO) design patterns and some multithreaded patterns as well. For example, we wanted to expose a big in-memory data structure safely to many threads. I had read about the Readers/Writer lock pattern, which used smart pointers (a C++ idiom) and coded a solution based on it.
Voila! It just worked. The concurrency bugs simply disappeared! Furthermore, the pattern made it very easy to reason about threads. In our case, a writer thread needed infrequent but exclusive access to the shared data structure. The reader threads just used the structure as an immutable entity—and look mom, no locks!
No locks! Well, well, well... this was something new! As the locks disappeared, so did any possibility of deadlocks, races, and starvation! It felt just great!
There was a lesson I learned here! Keep learning about design patterns and try to think about the design problem at hand - in terms of patterns. This also helped me reason better about the code! Finally, I had an inkling of how to tame the concurrency beast!
Design patterns are reusable design solutions for common design problems. The design solutions are design patterns. Your problem domain may vary, that is, the business logic you need to write will be applicable to solving the business problem at hand. However, once you apply the pattern, things just fall in place, more or less!
For example, when we code using the OO paradigm, we use the Gang Of Four (GOF) design patterns (http://wiki.c2.com/?DesignPatternsBook). This famous book provides us a catalog of design problems and their solutions. The strategy pattern is used by people in various contexts—the pattern though remains the same.
Some years later, I moved to the Java world and used the executor service to structure my code. It was very easy to develop the code and it worked without any major problem for months (There were other issues, but no data races and no nightmarish debugging!).
Subsequently, I moved to the functional world and started writing more and more Scala. This was a new world with immutable data structures as the norm. I learned about a very different paradigm; Scala's Futures and Akka Actors gave a whole different perspective. I could feel the power these tools give you as a programmer. Once you pass the learning curve (admittedly a little daunting at the beginning), you are equipped to write a lot safer concurrent code which is also a lot easier to reason about.
The book you are reading talks of many concurrent design patterns. It shows the rationale behind these patterns and highlights the design theme.
