C++, like most imperative languages, have a bad tradition in writing multi-threaded applications. Concurrency safety ranks first in terms of C++ development frustration (far ahead from the second place). This talk shows how concurrent C++ applications can be designed by shifting the focus from low-level synchronisation to a set of concurrency patterns that deal with higher-level constructs.
Lately, we often compare the time spent reading code versus the time spent in writing code. And, we somehow lump together the actual reading of the code with reasoning about the code. But, if we look closely, these are very different activities.
We discuss too much about reading code but too little on what it means to reason about code. This article tries to explore a few aspects of what it means to reason about code. I’ll try to propose a new metric for code complexity that can be formalized (to some degree) and another metric that seems more appropriate to our cognitive behaviours.
Composition and decomposition are probably the most important tools we have as software engineers. And yet, for multi-threaded programs that use locks and raw threads, composition and decomposition doesn’t properly hold.
This article tries to consider composition and decomposition of task systems, showing that task systems play nice with regards to those two.
Similar to gotos, raw threads and locks should be banished from day-to-day programming. Moreover, we have far better way to build concurrent applications.
Watch my ACCU 2021 talk to see more.
C++ parallel algorithms are great, right? Well, not quite. While they can be useful in some cases, they miss the point of what it means to have a proper concurrency design, at least for multi-threaded processing. They give one the false sense of comfort that good parallelism can be achieved by adding a parameter to a couple of algorithmic functions.