OVERVIEW
The Race Catcher UI provides you with a view of every project that was started in SUM Enabled mode, i.e. started using the "jta" convenience scripts. "jta" is placed in the script instead of "java" and stands for "Java Threads Analyzer", where SUM stands for the Software Understanding Machine.
In the case of an experienced thread contention, the project will be marked by an icon indicating the type of the contention, a race condition, or a deadlock. The project will be marked with either a racing man or a lock icon.
Race Catcher is a dynamic code analysis tool that automatically identifies and pinpoints experienced thread contentions in byte code when run by a JVM.
The UI component of the product provides the online report of the diagnosed contentions. The contentions are displayed mapped to the corresponding source code. Other synchronized with the source code views shows the contentions on special animated graphs representing automatically built models of the reported classes and methods.
While analyzing a bite code, this version of the product is allowing to see the analysis only in the case when the corresponding source code is accessible by the machine that has performed the analysis. That is verified by mapping the source to the analyzed issue. This way when the issues are found in the proprietary code, or in the open-source code, the user can simply point to the parent source code folder. Mapping the issues already analyzed on the byte code to the corresponding source code is then done automatically.
Issues most often present within software written to utilize Multi-core hardware.
Multi-core hardware increasingly affects the need for multi-threaded application development. The challenge of, and the need for creating multi-threaded applications will only increase with time.
This trend will create a higher prevalence of concurrency defects, which can easily slip through traditional testing techniques. The conditions that cause these defects are intermittent, meaning that they may not be present during the testing phase.
The conditions of concern are deadlocks and race conditions. Deadlocks are a state of indefinite wait. Race conditions are conditions of unpredictable results. These results are present when multiple threads access shared memory location while doing that in an undetermined order, and where at least one of those threads is changing that memory location's content (i.e.accesing it for 'write')
Race Catcher, from Thinking Software, Inc. has very specific advantages in comparison with other offerings. The main advantage is in the ability to treat this tool as an addition to your JVM, due to its:
-
High level of automation (operating completely automatically).
-
General ability to operate on a "Black Box" software process.
-
Absence of "false-positive" results (an extremely important characteristic)
-
Low, and also additionally configurable overhead.
Level of Automation
Race Catcher works on byte code, eliminating the need for any kind of integration in order to perform the process diagnosis:
-
Eliminating the need to integrate the tool with your development IDE.
-
Eliminating the need to integrate the source code with the tool.
That is, you would simply work as you normally do.
General Ability to Operate as a "Black Box Opener"
A software process does not need to have threads contention to be diagnosed by Race Catcher and be analyzed within the Race Catcher UI. One does not need to have access to source code to see the following:
Please see how this view demonstrates the following attributes of any class:
-
All fields of a class
-
All methods of a class
-
For each method:
-
All its parameters
-
All its allocations
-
Models of class methods
Advantages of Race Catcher
What False Positives - present in other tools - do to programmers' productivity
False-positive results harm our productivity. Try to find a black cat in a dark room when the black cat is not there.
False positives generally remove our trust in such tool.
Static analysis tools claim around 20% false positives while analyzing Race Conditions. However our tests of one of the Static Analysis tools, a well-known tool, produced 77% False Positives.
Best known Dynamic Analysis tools claims 15% – 20% False Positives.
However, Race Catcher Dynamic Analysis provides 0% False Positive results. And it does not miss any race condition experienced by an application.
Race Conditions
Unnecessary synchronization is doing harm by slowing an application down via obtaining unnecessary locks. That can be understood by imagining a synchronization of all the methods in the application – we would then completely lose the effect of multiprocessing.
Since Race Conditions are intermittent conditions of unpredictable results, and since applications with race conditions are running as “happy”, not crashing, and not generating exceptions, mode, catching only the actually experienced race conditions is extremely helpful.
It ensures that you do not waste time attempting to verify that a flagged issue is a 'real' race condition like it is done in the case of other tools.
Building Models of Application Classes
SUM models of software provide yet another dimension for the understanding of the software code. The software does not execute characters within statements. The software executes a logic of an algorithm. SUM models are built by extracting that logic from the code.
SUM model of a code is like a building, which is built in only one specific way, by a completely deterministic rule. That rule is the algorithm of that software process.
Deadlocks
A deadlock – a state of indefinite wait – refers to a specific condition where two or more threads are waiting for each other to release a resource, or more than two threads are waiting for such resources in a circular chain.
A simple deadlock is where there are only two threads involved. For example, Thread-1 waits for Thread-2 to release a lock (Lock2) while Thread-2 waits for Thread-1 to release a lock (Lock1). Neither thread can progress from that state.
More frequently, deadlocks involve multiple threads waiting for resources in a circular chain. An example of this form of deadlock condition can be understood by imagining four cars approaching a four-way intersection in clockwise order. Generally, the rule is that the driver on the right has the right-of-way. If the driver who gets to the intersection first waits long enough, the chain closes and another driver will appear to his right. Once all cars get to the intersection, they will be in a state of deadlock until one of the drivers breaks the rule.
When a software application is in a deadlock state, usually you may suspect that the application is deadlocked only after you become tired while looking at the screen and waiting for a result. JVM will report the presence of a deadlock only if you press the Ctrl and Break keys simultaneously. NetBeans IDE will diagnose a deadlock and map the problem to the source code automatically, but for that to be the case you must run your application in debug mode. Running your application in debug mode is a relatively slow way of executing your code. Additionally, thread contention failures are intermittent, and we cannot expect to catch all of them in the development stage.
Race Catcher automatically diagnoses deadlocks and pinpoints the source code responsible without the necessity of running your code in debug mode in a special environment such as NetBeans IDE, and without the necessity to look at the screen waiting to see whether the application is going to progress.
Race Conditions
A race condition occurs when more than one thread has simultaneous access to a shared memory location and when at least one access is for 'write'.
Access for 'write' is when a thread modifies the value of a memory location. Access for 'read' is when a thread simply obtains the value of the memory location.
"This situation is an example of a data race (§17.4.5). When code contains a data race, counterintuitive results are often possible."
Sun Microsystems, Inc., Chapter 17, "Threads and Locks," The Java Language Specification, Third Edition, January 2005, http://java.sun.com/docs/books/jls/third_edition/html/memory.html, (October 13, 2009).
NOTE: Race Catcher provides zero percent false-positive results during its automatic analysis of race conditions. It pinpoints the cause of race conditions via intercepting and diagnosing every manifested race condition.
Why dismissing some race conditions as “Benign” can be dangerous
If you search for “benign data races” you will find many research papers on what are “benign” races and what are “harmful” races, and what different approaches are tried in order to get closer to the truth, while getting less “false positives”.
You will run into the following classification of data races commonly used:
-
Harmful race conditions
-
Benign race condition
-
False Positive race conditions identifications
As far as the definition of “harmful” versus “benign” data races – we believe that the term “benign” is not really appropriate. What is “benign” today may be “malignant” tomorrow.
WE SAY: "A RACE CONDITION IS A CONDITION OF A RACE. AS SIMPLE AS THAT."
We Do Not Believe that the classification of a tool based on how many “harmful” races it finds versus how many “benign” races it finds is the best approach. We think it should be instead based on how many “real” races it finds versus how many “false positive race conditions” it finds.
Instead of "benign race condition" we would rather see the term “allowed race condition”, which would signify 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 an “allowed race” instead of “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”.
The Race Catcher 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 that user will know that the race was designed to be there.
Then the classification becomes much simpler
-
race condition
-
allowed race condition
Independent of these discussions, which are still expected to continue, Race Catcher is performing one unquestionably necessary job – positive identification of experienced by an application race conditions.
For more information, please refer to Advantages of Race Catcher.
Components - on a very high level
SUM User Interface – allows the user to view the result of the analysis automatically performed during targeted application execution.
Java Agent – Communicates to SUM Analytical Engine dynamic information about your target application.
SUM Analytical Engine – Analyses the information provided to it by the java agent.
Race Catcher Knowledge base (SUM_KB) – Is where the dynamically built knowledge of your application is being stored for later
viewing and additional analysis.
