ACM Home Page
Please provide us with feedback. Feedback
Types for atomicity
Full text PdfPdf (290 KB)
Source Types In Languages Design And Implementation archive
Proceedings of the 2003 ACM SIGPLAN international workshop on Types in languages design and implementation table of contents
New Orleans, Louisiana, USA
SESSION: Types and multithreading table of contents
Pages: 1 - 12  
Year of Publication: 2003
ISBN:1-58113-649-8
Also published in ...
Authors
Cormac Flanagan  HP Systems Research Center, Palo Alto, CA
Shaz Qadeer  HP Systems Research Center, Palo Alto, CA
Sponsors
SIGPLAN: ACM Special Interest Group on Programming Languages
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 16,   Downloads (12 Months): 96,   Citation Count: 23
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/604174.604176
What is a DOI?

ABSTRACT

Ensuring the correctness of multithreaded programs is difficult, due to the potential for unexpected and nondeterministic interactions, between threads. Previous work addressed this problem by devising tools for detecting race conditions, a situation where two threads simultaneously access the same data variable, and at least one of the accesses is a write. Unfortunately, verifying the absence of such simultaneous-access race conditions is neither necessary nor sufficient to ensure the absence of errors due to unexpected thread interactions.We propose that a stronger non-interference property is required, namely the atomicity of code blocks, and we present a type system for specifying and verifying such atomicity properties. The type system allows statement blocks and functions to be annotated with the keyword atomic. If the program type checks, then the type system guarantees that for any arbitrarily-interleaved program execution, there is a corresponding execution with equivalent behavior in which the instructions of each atomic block executed by a thread are not interleaved with instructions from other threads. This property allows programmers to reason about the behavior of well-typed programs at a higher level of granularity, where each atomic block is executed "in one step", thus signi .cantly simplifying both formal and informal reasoning.Our type system is sufficient to verify a number of interesting examples. For example,it can prove that many methods of java.util. Vector are atomic, even though some methods have benign race conditions, and would be rejected by earlier type systems for race detection.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

1
 
2
3
 
4
D. Bruening. Systematic testing of multithreaded Java programs. Master's thesis, Massachusetts Institute of Technology, 1999.
5
 
6
7
8
 
9
10
11
 
12
C. Flanagan and S. Qadeer. Types for atomic interfaces. Submitted for publication, 2002.
 
13
S. Freund and S. Qadeer. Checking concise specifications for multithreaded software. Submitted for publication, 2002.
14
15
 
16
 
17
L. Lamport and F. Schneider. Pretending atomicity. Research Report 44, DEC Systems Research Center, 130 Lytton Ave, Palo Alto, CA 94301, USA, 1989.
18
 
19
20
 
21
N. Sterling. WARLOCK --- a static data race analysis tool. In USENIX Technical Conference Proceedings, pages 97--106, Winter 1993.
 
22
23

CITED BY  24

Collaborative Colleagues:
Cormac Flanagan: colleagues
Shaz Qadeer: colleagues