On June 15, 2016, Thinking Software Inc. released 4 new versions of the most popular Linux distributions used on the cloud equipped with Race Catcher agents, which were published on the Amazon Web Services Marketplace: https://aws.amazon.com/marketplace/seller-profile?id=d31ec0d3-83e6-457e-ae97-9c885073c39f
These new versions of the Linux distributions (Ubuntu, RedHat, Amazon Linux, SUSE), equipped with Race Catcher agents from Thinking Software, Inc., allow for automatic and seamless verification and diagnostics of the reliability of the applications they run.
The degree of reliability automatically diagnosed here is related to the most complex issues in software, something that is impossible to pre-test. The term being referred to here is called a “race condition.”
Race conditions are the most complex to diagnose bugs in today’s multicore and multithreaded computing.
They are so common that many professionals say that any sufficiently complex multithreaded application is riddled with race conditions.
To see how true this statement is, simply search for “race condition” on the programmer forum Stack Overflow. There will be approximately 13,393 questions (growing approx. 2,000 per year) related to race conditions, each containing multiple answers. This is because prior to Race Catcher, there were no efficient ways to diagnose race conditions with 0% false positives.
Virtually all of the applications of today are multithreaded. A number of them are, in one way or another, trying to ensure “thread safety,” but none of these ways are so automatic as not to involve programmers on one step or another—not to mention that with humans come human errors and no way of proving a software program’s correctness.
To see the often destructive effect of race conditions on everyday life, look at the examples below.
Race conditions have similar effects to software viruses: They affect the results of one’s software. Like software viruses, they are intermittent and can stay within an application, dormant, for a long time before they act. With any multithreading software application, the results cannot be trusted unless you run the application with Race Catcher.
Examples of damage caused by “race conditions”:
- NASDAQ’s Facebook IPO glitch caused by a Race Condition
Cost: Facebook Investors $500M, NASDAQ $62M and the beginning of a possible downfall of their company
(Computerworld, May 21, 2012, http://www.computerworld.com/article/2504676/financial-it/nasdaq-s-facebook-glitch-came-from–race-conditions-.html)
- Mission to Mars almost failed due to a Race Condition
(Geek, Jan. 26, 2004, http://www.geek.com/chips/spirit-mars-rover-may-be-hobbled-by-a-software-glitch-555186/)
- Therac-25 fatally overdosed 6 patients due to a Race Condition
(Cunningham & Cunningham, Inc., May 12, 2011, http://c2.com/cgi/wiki?TheracTwentyFive)
- 2003 Northeast Blackout caused by a Race Condition
Cost: $6B (workers and investors lost $4.2B in income), at least 11 deaths
(Scientific American, Aug. 13, 2008, http://www.scientificamerican.com/article/2003-blackout-five-years-later/)
- Bank errors caused by Race Conditions lead to wrongful foreclosures
(Huffington Post, Jan. 27, 2012,http://www.huffingtonpost.com/2012/01/27/foreclosure-crisis-twisted-world-mortgage-lender-error_n_1236634.html)
Many programmers avoid this subject because it can be complex and prefer to trust their software applications results.
Most software application users don’t know that these issues exist and trust the programmers.
The newly released versions by the AWS Marketplace AMIs (Amazon Machine Images) of the popular Linux distributions (Linux, Red Hat, Amazon Linux, SUSE) bring out a big leap in the effectiveness of the Race Catcher technology. As many people know from physics about the “transformation of quantity into quality,” the more Race Catcher agents that are run on the same application, the sooner hidden race conditions will be experienced.
In this case, one can start tens, hundreds, or thousands of virtual machines all running the same applications. Being enriched with the Race Catcher, these VMs, in fact, start sharing a common and collective goal: Catch all of the instances of results’ unreliability.