http://drdobbs.com/high-performance-computing/225402247

“Ship is still turning”

“I always wanted time machines”

By James Reinders, June 08, 2010

James Reinders is Chief Evangelist and Director of Marketing for Intel’s Software Development Products. Reinders is a senior engineer who joined Intel Corporation in 1989 and has contributed to projects including the world’s first TeraFLOP supercomputer (ASCI Red), compilers and architecture work for a number of Intel processors and parallel systems. Reinders is the author of a new book “Intel Threading Building Blocks” from O’Reilly Media, monthly columnist for the “The Gauntlet” found online at go-parallel.com

The Free Lunch Is Over
A Fundamental Turn Toward Concurrency in Software

http://www.gotw.ca/publications/concurrency-ddj.htm

By Herb Sutter

http://en.wikipedia.org/wiki/Herb_Sutter

Sometimes people make a mistake by believing that atomic variables make accesses to these variable data race free.  For example, in case of a shared between threads AtomicBoolean variable one may assume that all accesses to this variable are data race free.

This misconception is a result of mixing two different understandings – of data race and of atomicity.   An atomicity insures uninterrupted by some other thread sequence of  operations on the data in scope of the atomic block of code or atomic variable update.

Alternatively, Data Race is a race on the subject of which thread will access a shared data first.  That is, of course, in case when at least one of these threads is modifying the shared data.  Data Race is about uncertainty on the order of accesses.

For example, an operation U implementing a database update on a value in a table is always implemented as an atomic operation.  Some operation R – reading the data would not be permitted on the same key while U is in progress.

However if we now have two different methods, M1 and M2 in two different threads – one calling the method U and another calling the method R on the same database key, while these two methods, M1 and M2, are not themselves synchronized, we will have the condition of uncertainty – a Data Race.  We would not know, are we going to read the data before it has been updated or after that.

By the same token, reading and writing a AtomicBoolean value by two or more different methods being executed from different threads at the same time in un-synchronized manner is a Race Condition.  We would not know with any certainty, are we reading after the write or before the write.

The atomic nature of the variable does not take away the condition for a race on its access.

You would run into the following classification of data races commonly used:

- Harmful race conditions
- Benign race condition
- False Positive race conditions identifications

As far as definition of “harmful” vs. “benign” data races – we believe that the term “benign” is not really appropriate.  What is “benign” today may become very “malignant” tomorrow.  By the same token, we believe that the classification of a tool based on how many “harmful” races it finds vs. how many “benign” races it finds we believe to be not the best approach, as well.  We think it should be instead based on how many “real” races it finds vs. how many “false positive race conditions” it finds.

We would rather see the term “allowed data race”, which signifies a data race that was designed to be there, for example in order to generate a random number.  Computing is really an exact science, mostly about 0-s and 1-s – not so much “maybe’s”.  We believe that race is a race and not-a-race is not a race.  If a race is designed to be allowed, it would probably be more appropriate to call it “allowed data race” but not “benign”.  The one that is called “benign” is most probably called such because it does not change results in any significant way or the change in results is not significantly important.  But what happens when a new addition to a code is built assuming that the code it is based on is deterministic and contains no behavioral uncertainty?  The “data race” that was previously ignored as “benign” now may cause serious unpredictability in the result and may become “malignant”.

SUM4Java approach is in identifying all experienced “real data races” while never falling for “false positives” providing 0% false-positive analysis.  It is as simple as 1 is not 0 and 0 is not 1 – black and white – no gray.  If a user chooses to classify a race as “allowed data race” it is a user’s choice – only user will know that the race was designed to be there.  Then the classification becomes much simpler:

• race condition
• allowed race condition

Software Understanding Machine ® (SUM) is a very sophisticated Dynamic Code Analyzer

SUM4  Java is the first release of SUM – a dynamic analyzer of Java applications completely automatically analyzing all the experienced Race Conditions with 0% False Positives rate.

The distinctive attributes of SUM4JTA are:

• Its relatively very low overhead
• Its 0% False Positive analysis rate
• Its original dynamic User Interface allowing to a non-programmer a level of understanding of computer programs
• Its ability to work directly on the byte code submitted to a JVM for execution, making this tool a true addition to the Java Virtual Machine.

If after purchasing a license for SUM4JTA you run into a Race Condition diagnosis that you consider to be a “False Positive”, while also sending us the test case proving your finding (this can be easily done via controlled by you built-in Email Notification mechanism), Thinking Software Inc. will not only provide you with a new version, addressing your issue, but will also extend your license for an additional month for free.

Programs run our lives. If we create them we own them for a while and then let them out to the world, like our children. Like our children, they may grow to appreciate their creators, or they may not. We may have to support them or they may learn to support themselves. The great thing about programs we create – they give us back as much as we invest in them. And you can always trust them as you trust yourself.  It is you after all who taught your programs what they know.

Open Source however is another animal, all together. You never know where it has been.

We can not prove program correctness for any non-trivial program. If a program is automatically created from specifications, some one still has to write the specification and the cognitive, manually created bugs will then be there.

Thinking Software, Inc. approach is in constant program understanding while the program runs. We do not call it testing. We call it Program Understanding. Testing tells you that a bug is found. Program Understanding tells you how program works even if no bug is found so far. And when a bug is found it will tell you all about the bug. Then you will know what needs to be changed.

What if a specification is changed. Testing would not help you there. But program understanding will. And it will tell you what needs to be changed in your program.

It is easy. Install “sum4jta”. Then use “jta” instead of “java” on your command line.

• Why be a blind “black box tester” when you can see the code you are testing?

• Why provide just the symptoms-like bug report when you can add to it the results of already performed analysis – no requirement for reproducing bug conditions – the code is already analyzed.