|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Interface Summary | |
---|---|
Detector | The interface for race detecting algorithms. |
Class Summary | |
---|---|
Access | This class represents one access of a program. |
ARInfo | This class represents detected atomicity violation which could lead to a data race. |
ARThread | A structure used for maintaining important thread dependent information for AtomRace. |
ARVariable | This class implements the core of the atomicity race detecting algorithm and contains variable related information. |
AtomRace | |
AtomRaceDetect | Implementation of the atomicity violation detection algorithm. |
Eraser | |
EraserDetect | The implementation of the Eraser algorithm. |
ERThread | Class takes care of the information gathered about the thread. |
ERThreadInfo | This class is used for keeping information about threads accessing concrete variable. |
ERThreadInfoCollection | This class provides access to the set of ThreadInfo objects - each represents a thread accessing shared variable from RDVariable. |
ERVariable | This class contains information gathered concerning the variable. |
LogProducer | A simple tool for writing to specified file. |
NoiseInjection | This class implements the noise injection based on ConTest util.Noise class. |
RaceDetector | The main class of the race detector. |
RDThread | This class is used for keeping information concerning a thread. |
RDThreadLocal | This class extends ThreadLocal used for storing variables local for a thread. |
RDVariable | This class is used for keeping information about program variable. |
RDVariableCollection | This class provides access to set of RDVariable (information concerning variable). |
RDVarSet | A set of variable names which are given in the file and can be used by RaceDetector in several cases. |
Enum Summary | |
---|---|
ERVariable.State | |
RaceDetector.DetectorImplementation | Available implementations of race detecting algorithms. |
RaceDetector.HealingMethod | Methods of healing: THREADS - Method based on the utilization of other processors (cores) in the system. |
RaceDetector.Operation | Read operation. |
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.
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.
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.
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.
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:
OTSTRONGYIELD - Method that uses bussy loop to repeatedly call yield till there is no thread within any problematic atomic section.
Healing
,
EraserDetect
,
AtomRaceDetect
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |