If you have ever done any software development under Microsoft Windows you have probably come across this famous error message:

System.IO.FileNotFoundException : Could not load file or assembly 'Acme.dll' or one of its dependencies. The specified module could not be found."

Naturally, when you see this message, you check whether Acme.dll is there, and what you usually discover is that the file is in fact there.

When dealing with computers, most error messages that you see tend to leave some room for troubleshooting, but when the system is reporting that a certain file does not exist, while the file is most certainly there, there is nothing to troubleshoot: the situation looks completely hopeless. The computer says black, but what you clearly see with your own eyes is white. You have just started, and you are already at an impasse. You are stymied.

Abstract

A Software Design Pattern for concurrent systems is presented, which makes race conditions something that can be asserted against and thus deterministically eliminated rather than stochastically reduced or minimized.

A description of the problem

Every Software Engineer who has dealt with concurrency knows that it is hard. The bane of concurrency is race conditions: when a thread accesses data without taking into account the fact that the data is shared with other concurrently running threads which may alter that data at any unforeseeable moment in time.

Here is the manual of the ventilation unit in English.

This is a little history of the early World Wide Web (WWW) for the benefit of the younger generation which may have not experienced the Internet in its infancy and therefore might not be aware of the horrors that it involved, and why certain things have come to be the way they are today.

As you are reading this, and thinking to yourself that it could not possibly have been as bad as I am describing it, remember, the general public was experiencing it using 2400 baud modems.

A Software Design Pattern which brings the principles of Inheritance, Encapsulation and Polymorphism one level up from the Class level to the Subsystem level, and offers a way of realizing relationships between classes so as to achieve dependency inversion by means of propagation instead of injection.

Part 1: Dependency Inversion

The software that we write often invokes other software to get parts of the job done. These are known as Services or Dependencies. If Class A is making use of some Class B, then Class A depends on Class B, so Class B is a dependency of Class A.

The principle of Dependency Inversion says that a class should not contain any direct calls to specific instances of any of its dependencies. Instead, it should receive these instances as parameters during initialization.

That's all very nice, but passing dependencies around can become quite a complicated business, and in large systems it can become a nightmare.

Let me start with a couple of pedantic definitions; stay with me, the beef follows right afterwards.

Conventional wisdom says that validation is different from error checking.

• Validation is performed at the boundaries of a system, to check the validity of incoming data, which is at all times presumed to be potentially invalid. When invalid data is detected, validation is supposed to reject it. Validation is supposed to be always on, you cannot switch it off on release builds and only have it enabled on debug builds.
• Error checking, on the other hand, is performed inside a system, checking against conditions that should never occur, to keep making sure that everything is working as intended. In the event that an error is encountered, the intent is to signal a catastrophic failure. Essentially, the term Error Checking is shorthand for Internal Error Checking. It can be implemented using assertions, thus being active on the debug build only, and having a net cost of zero on the release build.

So far so good, right?