Synchronization Aware Conflict Resolution for Runtime Monitoring using

Transactional Memory

Chen Tian, Vijay Nagarajan, Rajiv Gupta

April 6, 2008

Runtime Monitoring

Useful in many placesdebugging, profiling, security

Dynamic binary translation tools -DBTExample: Pin, Valgrind

Main task: instrumentation

load A, R1

store R2, B Mem.

Mem.

storeins Meta-data for A

storeins Meta-data for B

Shadow Mem.

Shadow Mem.

Actual instruction sequence

loadins r2, Xincins r2, 1

loadins r1, Xincins r1, 1

storeins r2 , X

Monitoring on Multicore MachineRace problem

Core 1

storeins r1 , X

load1 …

Core 2

load2 …

Wrong !

Solution ? Transactional memory - TM (J. Chung et al. HPCA’ 08)

Conflict !

start_tranx

end_tranx

start_tranx

end_tranx

Transaction sizenew instruction overhead VS abort overhead

Overhead and Transaction Size

Creating a transaction per basic block worst performance (over 60%)

Larger transaction is preferredTrace granularity and dynamic merging

0

5

10

15

20

25

Barnes Fmm Ocean-1 Ocean-2 Radiosity Raytrace Volrend

Ove

rhea

d (

per

cen

t)

4-BB

8-BB

12-BB

More about TM systemHardware and Software

This work focus on hardware - HTM

3 key functions:Memory version managementConflict detection

cache coherence message (HTM)

Conflict resolution

3 existing HTM designsEE – eager detection, requester losesEL – eager detection, requester winsLL – lazy detection, committer wins

start_tranx

end_tranx

Live Lock Problem

Example

start_tranx

end_tranx

…while (flag != 1) ;…

…flag = 1;…

…while (flag1 != 1) ;flag2 = 1;…

…flag1 = 1;while (flag2 != 1) ;…

ReasonDBT tools put the sync. into transactions

Especially for busy-waiting sync.

HTM doesn’t know the conflict is caused by sync.Fix it by making HTM sync.-aware

Core 1 Core 2

Abort!

EE Policy:Requester loses

Busy-waiting Synchronization Pattern

Spinning read and a remote writeFlag sync., locks, barriers

No !No !

Can I go?

Now you can go!

Yes !

Yes !

Remote Write

Spinning Read

Spinning read: a load repeated X times

Remote write: value changed by another thread

Hardware Implementation

Load table, Detector, Synchronization TableSimulated on Simics

New Conflict Resolution

Key idea:

A transaction which performs the

sync. write should be committed immediately!

Add two rulesWhen a sync. pattern is detected, notify the HTM

(avoid or break live locks due to sync.)

When a conflict is detected, check the syn_table

(ensure discovered sync. will not cause live locks )

...end_tranx

start_tranx…

start_tranx…flag = 1;end_tranx

Example

start_tranx

end_tranx

…while (flag != 1) ;…

end_tranx

…flag = 1;…

start_tranx

Synchronization

Detected!Abort!

Transaction 1 Transaction 2

When T1 comes again, it will see the updated

value of flag.

Accuracy of Sync. Detector

Splash-2 Programs

Actual No. Detected No.

Barnes 33 33

Fmm 59 55

Ocean-noncont. 44 44

Ocean-cont. 42 42

Radiosity 60 60

Raytrace 19 19

Volrend 35 35

Water-ns 24 24

Water-sp 28 28

Comparison with Time-out

Time-out solutionPeriodically check the progress

Re-instrumentation on the fly

Pay extra overhead (conflict may only happen once)

Our solution (relies on HTM, not DBT)No need for re-instrumentation

Only need to check when there is conflict

Thanks !

Any Questions?