Yes, you have read it right. Unless you are a compiler or a exploit developer you do not really want to know anything about stack canaries. You just need to know they exists and will prevent stack overflows. But if you want to know how they work in detail, then keep reading.

We had already briefly talked about atomics to implement a mutex. However, the use of atomics in the general case can be a bit tricky and fires some low level synchronisation issues that the programmer needs to be able to control. This is what the memory models are for.

Debugging, profiling and optimising concurrent applications is not easy, and there are not that many tools out there to deal with the specific issues of these special programs. Helgrind, part of the Valgrind project is one of those tools.

In the previous instalment we introduced the concept of Mutex and dived into the basics of its implementation, that is, atomic memory modification. As we announced at the end of that article, that is just half of the trick and now it's time to get the other half sorted out.

Concurrent programming have its own and special issues on top of the normal difficulties of writing SW. One of the problems we may find when writing concurrent SW is the so called Race Condition Situation.