1 / 14

LiteRace : Effective Sampling for Lightweight Data-Race Detection

LiteRace : Effective Sampling for Lightweight Data-Race Detection. Guy Martin, OSLab. Agenda. Introduction Background LiteRace Overview LiteRace Implementation Evaluation Limitations Conclusion. Introduction.

amaya-weiss
Télécharger la présentation

LiteRace : Effective Sampling for Lightweight Data-Race Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LiteRace:Effective Sampling for Lightweight Data-Race Detection Guy Martin, OSLab

  2. Agenda • Introduction • Background • LiteRace Overview • LiteRace Implementation • Evaluation • Limitations • Conclusion [MaMN09] - LiteRace

  3. Introduction • Data Race: Happens when multiple threads perform conflicting data accesses without proper synchronization operation. • Sampling: Act of gathering representative samples; Process of collecting specimens; Process of taking a small portion of something as a specimen [Babylon online dictionary] • Cold Region Hypothesis: Data races are likely to occur when a thread is executing a “cold” (infrequently accessed) region in the program • Hot Region: Frequently accessed region in program. [MaMN09] - LiteRace

  4. Introduction: Happens-Before • The happens-before  is a partial order on the events of a particular execution of a multithreaded program • ab if a and b are events from the same sequential thread of execution and a executed before b • ab if a and b are synchronizations operations from different threads such that the semantics of the synchronization dictates that a precedes b. • The relation is transitive, so if ab and bc, then ac • A data race is defined as a pair of accesses to the same memory location, where at least one of the accesses is a write, and neither one happens-before the other. [MaMN09] - LiteRace

  5. Introduction: Happens-Before Time Thread 1 Thread 2 Time Thread 1 Thread 2 Lock L Lock L Write X Write X Unlock L Unlock L Data race on X Lock L Lock L Write X Write X Lock L Unlock L Unlock L Properly synchronized accesses to a memory location X. No data race No happens-before relation between the two write operation on location X [MaMN09] - LiteRace

  6. Background • Problem: Dynamic race detectors incur high runtime overhead into analyzed programs. • RaceTrack: 2x to 3x slowdown • Intel Thread Checker: 200x overhead • Why?Happens-before relation and Lockset based algorithms check all accesses to a shared memory • Source of runtime Overhead in happens-before relation • Instrumentation of all memory and all the synchronization operations • Upkeep of metadata for each accessed memory location (usage of vector clocks) • Solution:LiteRace, a lightweight data races detector based on the cold-region hypothesis that samples and analyzes only selected portions of a program’s execution. [MaMN09] - LiteRace

  7. Background - Motivation • Dynamic data races detection tools can not find all data races in a given program • They find data races only on thread interleavings and paths explored at runtime…  …Some false negatives can then be tolerable • Sampling techniques provide a useful knob that allow users to trade runtime overhead for coverage. • Users can increase or decrease the sampling rate according to the analyzed program behavior. [MaMN09] - LiteRace

  8. LiteRace Overview Time Thread 1 Thread 2 Lock L • Which events to log? • Synchronization operations along with logical timestamp to reflect happens-before relation • Reads and writes to memory in the program order Write X False data race reported on X Unlock L Lock L Lock L Write X Unlock L Any missed synchronization operation can result in missing edges in the happens-before graph but a selective sampling of memory accesses is acceptable. [MaMN09] - LiteRace

  9. LiteRace Overview X86 function • 2 copies are created for each function • A Dispatch Check is inserted at the entry of each function • Initial sampling rate for every region is set to 100% • Whenever a region is accessed, its sampling rate is decreased until it reaches a lower bound • Separate sampling information is maintained for each thread • Sampling portion of code are logged and analyzed offline using happens-before algorithm LiteRace Dispatch Check (Sampler) When Cold Usually Un-instrumented copy Instrumented copy Original Code + Log Synchr. Ops Original Code + Log Synchr. Ops + Log Memory Ops LiteRace Instrumentation [MaMN09] - LiteRace

  10. LiteRace Implementation Dispatch Function Decrement the Sampling Counter • LiteRace maintains a buffer for each thread containing 2 counters for each function • Frequency counter: tracks the number of times a function has been executed and determines the sampling rate • Sampling counter: determines when to sample a function • SyncVar uniquely identifies the synchronization object and a logical timestamp representing the order in which the thread perform operation on that objet. Sampling Counter = 0 ? Un-instrumented function Original code + log synchr. ops NO YES Instrumented function Original code + log synchr. & memory ops Sampling Counter Is set to a new value based on current sampling rate LiteRace Code Instrumentation Happens-before relation tracing [MaMN09] - LiteRace

  11. LiteRace Implementation • Tracking Happens-before relation with SyncVar T2 T1 It’s guaranteed that an Unlock operation on a particular mutex will have a smaller timestamp than a subsequent Lock operation on that same mutex in another thread. ts3 ts1 < ts4 ts2 [MaMN09] - LiteRace

  12. Evaluation • LiteRace has been implemented on Windows Server 2003 with two dual-core AMD Opteron and 4GB of RAM • LiteRace is implemented using Microsoft’s Phoenix compiler. It instruments directly the x86 executable file of a program. • LiteRace found about 70% of data races on its benchmarks when incurring about 28% performance overhead for unlogged execution and is up to 25 times faster than an implementation that logs all memory operations. [MaMN09] - LiteRace

  13. Limitations • LiteRace introduces false negatives by analyzing just samples of runtime interleaving. • The overhead introduced (28%) still high and unsuitable for certain applications. • The Dispatch Check is inserted at the entrance of every function. This function need to be as small and efficient as possible. [MaMN09] - LiteRace

  14. Conclusion • Dynamic race detection tools incurs high overhead in analyzed programs • LiteRace is a sampling-based technique which tries to ameliorate the runtime performance overhead of dynamic races detectors. • By logging less than 2% of memory accesses, LiteRace can detect more than 70% of data races using an offline happen-before race detector. • The sampling-based technique offers a knob in term of sampling rate, which the programmer can use to trade-off performance for data-race coverage. [MaMN09] - LiteRace

More Related