1. Healing Data Races On-The-Fly
Bohuslav Krena, Zdenek Letko, Rachel Tzoref, Shmuel Ur, and Tomas Vojnar
Ok-Kyoon Ha
OS Lab., GNU

2. Contents Background Motivation Self-Healing Steps Experiment
Problem Detection
Problem Localization
Problem Healing
Healing Assurance
Experiment
Conclusion

3. Background- what is a race?
A data race occurs when two concurrent threads access a shared variable
- at least one access is a write
- the accesses are unordered by any synchronization
Usually a data race is a serious error caused by failure to synchronize properly.
This paper distinguishes races
- Atomicity races
- Inherent races

4. Background- Atomicity Races
Races caused by violation of wrong assumptions that some blocks of code will be executed atomically
Thread 1
Thread 2
void someMethod( ){
shared = update(shard); }

5. Background- Inherent Races
Races not related to atomicity
Data race if the following holds:
Executing any segment of cod in each thread atomically does not determine an order of accesses to shared variable.
The different orders in which the shared variable is accessed can be classified as “good” and “bad” according to the expected behavior of the program.

6. Motivation
Race detection tools do not verify some of the races, or they can report many false alarms.
Even if the problems are known in the best testing or verification techniques, there are situations in which it is not easy to fix it.
- embedded software in hardware requires expensive cost for solving it
(replacing, updating)
If the software could fix its concurrency problems itself on-the-fly, it would be very desirable.

7. Self-Healing Steps Problem detection Problem localization
Problem healing
Healing assurance
to detect that something is wrong with the system
to find the root cause of the problem
applying a fix to the problem using the localization stage
to check/prove the self-healing action

8. Problem Detection Eraser algorithm Principle:
- Detects so called apparent data races
Principle:
- For each variable maintains its state and the set of candidate locks
- Race is detected whenever:
+ the variable is state shared
+ the set of candidates locks becomes empty

9. Extended Eraser Algorithm
Virgin – the variable has not been initialized yet.
Exclusive – the variable is accessed only by the thread which initialized it.
Shared – the variable is read by multiple threads.
Shared-modified – the variable is read and written by multiple threads.
Race – a data race on this variable has been detected (due to no or a wrong lock has been used when accessing the variable).
Figure 1: Possible states of a shared variable

10. An Example of Detection
Main T1 T2
bookTicket ( );
<lock>
static class Flight {
private int soldSeats; …
Flight ( ) {
soldSeats = 0; }
boolean bookTicket ( ) {
soldSeats++;
new Flight ( );
bookTicket ( );
Time
Shared
<T1>
C(v) = {lock}
Exclusive
<Main>
C(v) = {}
Virgin
Race
<T2>
C(v) = {}

11. Problem Localization Often hard work even for programmer.
This paper uses pre-specified data race bug patterns in the code with the aid of information collected by race detector
Use formal methods to reduce the number of false alarms but with reasonable overhead.

12. Atomicity Violation Bug Patterns
load-store bug pattern
x++;
test-and-use bug pattern
if (p != null)
p = p.next;
repeated test-and-use bug pattern
while (p != null)
0: aload_0
1: getfield #2
4: ifnull
7: aload_0
8: aload_0
9: getfield #2
12:getfield #3
15:putfield #2
18: …

13. An Example of a Bug Pattern
static class Flight {
private int soldSeats; …
Flight ( ) {
soldSeats = 0; }
boolean bookTicket ( ) {
soldSeats++;
2: getfield #2
5: iconst_1
6: iadd
7: putfield #2

14. Healing Atomicity Races
Influencing the scheduler
Forcing a context switch: yield( ) or sleep(0)
to guarantee full time for atomicity execution from the scheduler
safe and legal solution
only decrease the probability of race manifestation T1 T2
Thread.yield( );
2: getfield #2
5: iconst_1
6: iadd
7: putfield #2
2: getfield #2
5: iconst_1
6: iadd
7: putfield #2

15. Healing Atomicity Races
Influencing the scheduler
Temporary changes of the priorities
to guarantee full time for atomicity execution from the scheduler
safe and legal solution
only decrease the probability of race manifestation
strongly dependent on OS and JVM
Thread.setPriority (MAXPRIORITY); …
Thread.setPriority (originalPriority);

16. Healing Atomicity Violation
Adding Synchronization Actions
Suitable use of mutexes (locks).
to prevent accesses being simultaneous
heal the race
can introduce new (and even more dangerous) bugs: deadlock
HealingMutex.lock ( ); …
HealingMutex.unlock ( );

17. Healing Inherent Races
Distinguish between “good” and “bad” orders
Thread 1
1) done = false
Thread 2
for (int i=1; i<100; i++) {
print (i); }
done = true
raceLock.lock( );
raceLock.unlock( );
Thread 2 → Thread 1 : Bad order (done = false)
Thread 1 →Thread 2 : Good order (done = true)

18. Healing Inherent Races
enforce on “good” order
change the scheduling of the program: wait( ) and notify( )
Thread 1
raceLock.lock ( );
done = false
raceLock.unlock ( );
Thread 2
for (int i=1; i<100; i++) {
print (i); }
raceLock.lock ( );
done = true
raceLock.unlock ( );
wait ( );
notify ( );

19. Healing Inherent Races
override “bad” order
concentrate on write accesses
does not prevent bad order from occurring
Thread 1
raceLock.lock ( );
done = false
raceLock.unlock ( );
Thread 2
for (int i=1; i<100; i++) {
print (i); }
raceLock.lock ( );
done = true
raceLock.unlock ( );
assume that we know good order (T1 → T2)
only maintains T2’s value, if it execution bad order (T2 → T1)

20. Healing Assurance static analysis or bounded model checking
reduce false alarms during detection and localization
ensure that a new bug can not be introduced
help to choose suitable healing method

21. Preliminary Results Implemented race detector is able:
to detect wrong locking policy using Eraser algorithm
to detect load-store atomicity bug pattern
to localize the race and give enough information to the developer
to heal founded race by influencing scheduler and also by additional synchronization

22. Experiments
made all the tests on 1, 2, and 4 processor and for 2, 3, 5, 10, and 15 working threads
heals the race in all cases by new explicit lock

23. Related Work ToleRace tool concentrates on asymmetric races
based on transforming the critical regions of code
at the end of the region check a race
can “tolerate” it by producing the correct result based on the local copies of shared variables
possible to heal only a read-write race
does not heal write-write races

24. conclusion
applies self-healing in the context of fixing data races in the Java programs
explained three bug patterns leading to data races
proposed possible self-healing actions to be taken when a bug pattern is detected
Future work
implementation of efficient healing techniques
[LeVK08]