Delivering full-featured applications requires developers to take advantage of multi-core processor capabilities. This added complexity brings additional security/quality challenges that developers must understand and mitigate early in the development lifecycle. CodeSecure provides advanced analyses for finding defects in multi-core development.

The defects that are unique to multi-threaded and multi-core code are notoriously difficult to find, let alone replicate in a testing environment. CodeSonar, CodeSecure's leading static code analysis tool, detects these complex concurrency-related defects, discovering and reporting problems such as deadlocks, livelocks, resource starvation, and race conditions.

Developers responsible for building sophisticated multi-threaded code consistently choose CodeSecure to help identify and eliminate complex concurrency defects early in the development lifecycle when they are most cost effective to fix.

CodeSonar checks many different scenarios for misusing concurrency APIs. Deadlocks and data races are particularly time-consuming and expensive to fix when left undetected throughout development because they cause a disproportionate number of concurrency-related bugs throughout a program.

Manual testing is not very effective at detecting and debugging data races, for example, because it is infeasible to test every interleaving in real-world systems. This is where CodeSonar's data race detection is extremely effective. CodeSonar detects data races by focusing on the causes of the data race, not the symptoms. CodeSonar examines the code and creates an abstract model of what locks are held by what threads. It considers possible interleaving in an automated way, examining patterns of access to shared memory locations, and finds situations in which code is susceptible to problematic interleaving.

CodeSonar's advanced concurrency checks for C/C++ were developed and commercialized through a CodeSecure Research project funded by DARPA. In addition to multi-threaded software, CodeSonar also finds bugs in signal handlers.

An example of a partitioned system using virtualization on a multicore platform. Separation by criticality and function are possible.

Concurrency checks for Java are available through ThreadSafe, the most advanced concurrency bug finder available for Java, which finds problems that are missed by other tools.In addition to identifying race conditions and deadlocks, ThreadSafe can pinpoint unpredictable results caused by incorrect use of the concurrent collection libraries provided by java.util.concurrent, bad error handling, or incorrect synchronization when coordinating access to shared non-concurrent collections. It can also help diagnose performance bottlenecks caused by incorrect API usage, redundant synchronization, and unnecessary use of a shared mutable state.

CodeSonar catches complex concurrency-related defects in multi-threaded and multi-core code, like data race, deadlocks and incorrect use of synchronization techniques.

Data races cause a disproportionate number of concurrency-related bugs, that are detected extremely effectively by CodeSonar. A data race can be caused by

• Multiple threads of execution access a shared piece of data.
• One thread that changes the value of the data.
• An access that is not separated by explicit synchronization.

Data races can leave a system in an inconsistent state, which can remain undetected and only show up in unusual cases with curious symptoms. Because of the huge number of possible executions, the detection and debugging of data races, and concurrency problems in general, cause difficulties for traditional testing methods.

As can be seen from the figure above, there are six possible interleaving of two threads with two instructions each. With three instructions each, there are twenty possible interleaving. Due to the variety of combinations, it is infeasible to test every interleaving in real-world systems. The diagnosis of data races proves to be rather difficult, because the defect occurs only under certain interleaving. Data races are sensitive to traditional tools like debuggers, which affect timing and can make the bug disappear temporarily.

In contrast to traditional tools CodeSonar detects data races by focusing on the causes, not the symptoms. The tool examines the code and creates an abstract model of what locks are held by what threads. It considers automatically possible interleaving, examines patterns of access to shared memory locations, and finds situations in which code is susceptible to problematic interleaving. As soon as CodeSonar identifies a data race, the tool issues a data race warning that includes supporting information.
Contrary to the widespread assumption that some types of data races are harmless, they can cause damage during execution. This is because optimizing compilers reorder instructions.

Deadlock means a situation in which two or more threads prevent each other from making progress by each holding a lock needed by another. The most common approach to avoiding deadlock is to ensure a partial ordering to the resources. This way was proposed by Dijkstra in 1965 as a solution to the Dining Philosophers Problem. A large code base makes it difficult to tell through manual inspection if the software follows this rule. The automated analysis of CodeSonar issues a warning if the same locks can be acquired in different orders by different threads.

Moreover, the tool provides a nested locks check, to avoid these dangerous defects. This check triggers a warning whenever a thread tries to obtain two or more locks. Depending on the requirements the nested lock check can be enable or disabled.

In a deadlock, both threads are completely stuck, both unable to carry out their operations or get to the point where it can release its lock