An Abstract memory model describing the interaction between thread and memory with debugger tools Shruti Sandal #1 , Dr.Raghuraj Singh *2 , Abdul Jabbar Khilji #3, ,Shashi Shekhar Ranga #4, sanjay tejasvee #5 #Assistant professor Department Of Computer Application Engineering College Bikaner *Head of Department of Computer Science & Engineering Department, H.B.T.I., Kanpur #1shrutisandal@yahoo.com,#3khiljisania746@gmail.com,#4ranga.ssr@gmail.com, #5sanjaytejasvee@gmail.com *raghurajsingh@rediffmail.com Abstract:-This paper describe the multithreaded execution and data race detectors which are commonly viewed as debugging tools.The C++ Standard defines single-threaded program execution. Basically, multithreaded execution requires a much more refined memory and execution model. C++ threading libraries are in the awkward situation of specifying an extended memory model for C++ in order to specify program execution. We suggest integrating a memory model suitable for multithreaded execution in the C++ Standard. We wants to make fast and error free program .but ideally it is not possible To overcome this problem we give first concept threading and ssecond concept in this paper is data race detector. They would allow us to give precise, simple, and safe semantics to shared variables in multithreaded programs, a problem that has so far defied a complete solution. Keyword:-atomicity,data race. I INTRODUCTION multithreaded execution. is use in most of today’s programming. C++ is commonly used as part of multithreaded applications, sometimes with either direct calls into an OS- provided threading library or with the aid of an intervening layer that provides a platform-neutral interface. Properties critical for reliable, efficient, and correct multithreaded execution are left unspecified The C++ Standard specifies program execution in terms of observable behavior, which in turn describes sequential execution on an implicitly single- threaded abstract machine. The main sketch of attack is: 1. Specification of an abstract memory model describing the interactions between threads and memory. 2. Application of this model to existing aspects of the C++ specification to replace the current implicitly sequential semantics. This will entail new constraints on how compilers can emit and optimize code. In particular, this will entail a reworking of the specification of volatile to provide useful multithreaded semantics. 3. Introduction of a small number of standard library classes providing standardized access to atomic update operations (such as compare_and_set). These classes will have multithreaded semantics integrated with the above specifications for other memory operations. Thus, compilers will need to treat these as intrinsic. These operations form the low-level basis for modern multithreaded synchronization constructs such as locks, and are also required in the construction of efficient non-blocking data structures. 4. Definition of a standard thread library that provides similar functionality to threads and Win32 threads, but meshes with the rest of the C++ standard. Secondly Data races are well-recognized as a common source of particularly difficult-to-diagnose bugs in parallel programs. As a result many tools have been built to explicitly detect data races, either at compile time, or as the program is executing).Although code correctness typically requires stronger properties, such as atomicity[7] or even determinacy, data-race-freedom remains interesting since it is a well-defined condition that is easy to check, even in the absence of any additional programmer supplied specifications. This is particularly true for a number of important language specifications, notably the expected upcoming revisions of the C and C++ language standards [14, 11, 15] and the much earlier Posix threads [10] and Ada [17] standards, that explicitly treat all data races as programmer errors [1]. In these languages, an accurate (no false positives) data race detector, such as [6] or [8], by definition diagnoses only actual errors II WHY DATA RACE IS VIEWED AS DEBUGGER TOOL There are two additional reasons we would really like to see an accurate mechanism for detecting and avoiding data races, e.g. by throwing an exception as in [6]: 1. Data-race-free programs are independent of the granularity at which memory accesses are performed. They exhibit the same behavior on a machine that accesses memory a byte-at- a-time as it does if memory is accessed 64 bits at a time. Similarly, accesses to library or user-defined synchronization- free data structures behave atomically. In both cases, a half- updated data structure can’t be observed by another thread, since the observer thread would introduce a data race.Note that this property is orthogonal to sequential consistency. Shruti Sandal et al. / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 1 (5) , 2010, 324-328 324