Delphi Thread Safety Patterns book available on Amazon

-

Delphi Thread Safety Patterns book is now available as paperback on Amazon, too. 




While the thread safety of a particular piece of code depends on the surrounding context and how it is used, some data types are inherently unsafe, and for some of them, thread safety will depend on the use case and the specific code. Unfortunately, when you look at some class, type declaration, or API in isolation, there is very little information there that will tell you whether instances of that type can be safely used in multiple threads, or under which conditions.

The proper place to learn about the thread safety of an API is its documentation. However, most documentation will not explicitly give you that information. Occasionally, the documentation will mention that a particular feature is not thread-safe, or will tell you that a feature can be used in background threads, but for the most part, you will have to figure out thread safety on your own. One reason for this is that thread safety depends on the context. The number of features that are absolutely unsafe or are absolutely safe is very small.

The basic thread safety rules are simple, but applying those rules is more complicated. Just as design patterns give us general solutions to common coding problems, we can extract common coding patterns from various multithreaded code—thread safety patterns.

This book converts the thread safety rules into practice, and gives an overview of core Delphi frameworks and commonly used features from a thread safety perspective. You will find examples of how particular classes can be used in a thread-safe manner and how to perform some common tasks, following the already established thread safety patterns.

Besides elaborating on the thread safety of particular parts of Delphi frameworks, the book explores the thread safety of alternate solutions, along with general coding examples. Every explanation about why some code is thread-safe or not, also serves as an example of thread (un)safety patterns, and helps in recognizing thread-unsafe code, as well as establishing a working set of thread safety patterns that can later be applied in custom code.

Those examples, covering the most commonly used parts of Delphi frameworks, will also serve as learn by example pointers for determining the thread safety of other parts of the frameworks, and even of 3rd-party libraries that are not specifically covered in this book.

There are also implementations and examples of some commonly used concepts in asynchronous programming that are not part of the core Delphi frameworks, but can be indispensable when writing multithreaded code.

Comments

Post a Comment

Popular posts from this blog

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more

Beware of loops and tasks

-
Loops and anonymous methods don't go hand in hand. Any variable that changes for each iteration will cause problems if it is used within an anonymous method. I explained the mechanism behind variable capturing in the post Mysterious Case Of Wrong Value , along with the problem it causes with loops and its solution. Commonly, anonymous methods are used as callbacks or event handlers, where there are no loops in the context where variable capture happens. While there is a possibility to have an unexpected—wrong—value in such scenarios, it is rather easy to debug them and understand the order in which some code is called, and why the captured value is wrong in a given place. With the rise of multi-threading usage, and especially the Parallel Programming Library and tasks, writing anonymous methods inside a loop becomes more common, and it is much easier to write code where a captured variable will have the wrong value. The biggest problem with such code is that it will be harder to
Read more

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more