Race detector for IBM ConTest

What is a data race?

A data race occurs when two concurrent threads access a shared variable and when:

Usually a data race is a serious error caused by failure to synchronize properly.

What is an atomicity violation?

Atomicity violation occurs if a block of code that operates with some variable and is intended to be executed without unwanted inference with other running threads is interleaved by some other thread which touches the variable and so causes such unwanted inference. For example, when one thread is executing a block of code incrementing a variable x (x++;), other threads should not change the value of x.

Eraser algorithm

Race Detection & Healing tool can use modified version of the Eraser algorithm to detect violations in a locking policy. It is simply trying to identify which lock is used to protect a shared variable. If some thread access a shared variable without a proper lock, a race warning is logged. Eraser also tries to identify the lock which should be used with the shared variable and suggests to programmer to use it. Eraser maintains for each shared variable a set of locks used with it. The set is build since the variable becomes shared. If the set becomes empty the race warning is produced.

Eraser algorithms does not supports other than synchronized{} based, Thread.join() based synchronization primitives.

AtomRace algorithm

Race Detection & Healing tool can use a new algorithm AtomRace for detecting atomicity violations. This algorithm can be used for detecting both data races (detected as a special kind of atomicity violation) and violation of predefined atomicities (block of code that should be executed without unwanted inference).

Data race detection is based on straightforward application of data race detection. Each instruction accessing a shared data is enclosed by pseudo instructions beforeAccess and afterAccess which delimits a primitive atomic section span just only one instruction – the one which access a shared variable. AtomRace algorithm then checks if two primitive atomic sections defined around accesses to the same shared variable does not overlap. Overlapping of such sections implies that accesses are being simultaneous and data race is possible. Of course, a chance on detecting such situation is sometimes very low. Therefore this approach can be combined with noise injection technique which injects noise within primitive atomic sections and so makes them longer what increases the probability of detecting data race.

Of course atomic sections can be constructed to span more than only one instruction. In such a case, atomic section starts at beforeAccess to a shared variable and has several ending points. At least one of ending points is afterAccess to the same shared variable. Atomic section in this case span two or more accesses to the shared variable. Other ending points cover situations when an execution takes different execution path which does not contain afterAccess operation. When an overlapping of such atomic section and any other atomic section which can not be serialized is detected, warning concerning atomicity violation is produced. Again, the noise injection technique can be used to increase the probability of hitting the problem.

Thread executing atomicity

Other thread

Problem description

read - write

write

The second write relies on a value from the preceding read that is overriden by other thread.

read - read

write

The write by other thread makes the two reads have different views of the variable.

write - write

read

Intermediate result that is assumed to be invisible to other threads is read by a remote access.

write - read

write

The read does not receive the local result it expects.

All these scenarios are unserializable (more can be read for example in the article of AVIO tool). If some of this scenarios is detected the atomicity violation warning is produced.

Healing of detected violations

The basic idea of healing is that Race Detection & Healing tool tries to force the predefined correct atomicity. If there is a race or atomicity violation over a variable and if there is predefined atomicity present, the Race Detection & Healing tool use selected method to minimize the probability of context switch in the middle of the problematic atomicity section. Several methods has been implemented and are briefly described later in this text.

Several methods for forcing predefined correct atomicity have been designed and implemented. Most of the methods below are not able to heal detected problem totally but they can decrease the probability of its manifestation. The only exception is the NEWMUTEX method which can really force the predefined correct atomicity. But because there are no checks if the locking is legal yet, this method can cause deadlock. Available methods for healing:

@see cz.vutbr.fit.healing.Healing @see cz.vutbr.fit.racedetector.EraserDetect @see cz.vutbr.fit.racedetector.AtomRaceDetect @author Zdenek Letko, xletko00@stud.fit.vutbr.cz