Automatic Mutual Exclusion and Atomicity Checks

Abadi, Martı́n

doi:10.1007/978-3-540-68679-8_32

Cited by 6 publications

(16 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our effect system exploits this connection to also verify atomicity specifications, in a manner similar to [1]. Indeed, we believe that atomic and yield are compatible and complementary specification idioms.…”

Section: A Motivating Examplementioning

confidence: 97%

“…Our yield effect system was inspired by work on automatic mutual exclusion, a recently proposed concurrency programming model based on having mutual exclusion by default [1,2,29]. A key difference is that automatic mutual exclusion enforces a yield annotation at run time, while our effect system uses static analysis to check that yield annotations provide equivalent cooperative execution.…”

Section: Related Workmentioning

confidence: 99%

“…If multithreaded reasoning is required, then this code becomes a potentially non-atomic read-modify-write sequence (with no syntactic hints to reflect this sea change from traditional, sequential semantics). 1 We assume that x is volatile, to avoid memory model complexities. …”

mentioning

confidence: 99%

“…First, atomicity forces a form of bimodal sequential/-multithreaded reasoning. To illustrate this point, consider the simple code fragment 1 :…”

mentioning

confidence: 99%

See 3 more Smart Citations

Effects for cooperable and serializable threads

Flanagan

2010

Proceedings of the 5th ACM SIGPLAN Workshop on Types in Language Design and Implementation

View full text Add to dashboard Cite

Reasoning about the correctness of multithreaded programs is complicated by the potential for unexpected interference between threads. Previous work on controlling thread interference focused on verifying race freedom and/or atomicity. Unfortunately, race freedom is insufficient to prevent unintended thread interference. The notion of atomic blocks provides more semantic guarantees, but offers limited benefits for non-atomic code and it requires bimodal sequential/multithreaded reasoning (depending on whether code is inside or outside an atomic block).This paper proposes an alternative strategy that uses yield annotations to control thread interference, and we present an effect system for verifying the correctness of these yield annotations. The effect system guarantees that for any preemptively-scheduled execution of a well-formed program, there is a corresponding cooperative execution with equivalent behavior in which context switches happen only at yield annotations. This effect system enables cooperative reasoning: the programmer can adopt the simplifying assumption of cooperative scheduling, even though the program still executes with preemptive scheduling and/or true concurrency on multicore processors. Unlike bimodal sequential/multithreaded reasoning, cooperative reasoning can be applied to all program code. Keywords Effect system, yield, atomicity, race conditions Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. TLDI'10, January 23, 2010, Madrid, Spain. Copyright c 2010 ACM 978-1-60558-891-9/10/01. . . $10.00 Categories and Subject Descriptors Controlling Thread InterferenceMultiple threads of control are widely used in software development because they help reduce latency and increase throughput on multicore and multiprocessor machines. Reasoning about the behavior and correctness of multithreaded code is difficult, however, due to the need to consider all possible interleavings of the various threads. Thus, methods for specifying and controlling the interference between threads are crucial to the cost-effective development of reliable multithreaded software.Race Freedom Early attempts at controlling thread interference focused on race conditions, where two threads access a shared variable at the same time, and at least one access is a write. Race freedom ensures that thread interference occurs only at certain actions (those that manipulate volatile variables, locks, semaphores, etc). By itself, race freedom does not entirely prevent errors due to unexpected interactions between threads. We illustrate this limitation via the following code, in which the shared variable x is protected by the lock m, and t is a thread-local variable:acquire(...

show abstract

Section: A Motivating Examplementioning

confidence: 97%

Section: Related Workmentioning

confidence: 99%

mentioning

confidence: 99%

“…First, atomicity forces a form of bimodal sequential/-multithreaded reasoning. To illustrate this point, consider the simple code fragment 1 :…”

mentioning

confidence: 99%

See 2 more Smart Citations

Effects for cooperable and serializable threads

Flanagan

2010

Proceedings of the 5th ACM SIGPLAN Workshop on Types in Language Design and Implementation

View full text Add to dashboard Cite

show abstract

“…Our convention of highlighting AC operations corresponds to rules from "atomic by default" programming models such as AME [2,19] and TIC [30] that operations that are not atomic should include annotations at the function's definition, and at each call-site. Our convention could be enforced by static checks, if desired.…”

Section: The Async and Dofinish Constructsmentioning

confidence: 99%

Ac

et al. 2011

View full text Add to dashboard Cite

This paper introduces AC, a set of language constructs for composable asynchronous IO in native languages such as C/C++. Unlike traditional synchronous IO interfaces, AC lets a thread issue multiple IO requests so that they can be serviced concurrently, and so that long-latency operations can be overlapped with computation. Unlike traditional asynchronous IO interfaces, AC retains a sequential style of programming without requiring code to use multiple threads, and without requiring code to be "stack-ripped" into chains of callbacks. AC provides an async statement to identify opportunities for IO operations to be issued concurrently, a do..finish block that waits until any enclosed async work is complete, and a cancel statement that requests cancellation of unfinished IO within an enclosing do..finish. We give an operational semantics for a core language. We describe and evaluate implementations that are integrated with message passing on the Barrelfish research OS, and integrated with asynchronous file and network IO on Microsoft Windows. We show that AC offers comparable performance to existing C/C++ interfaces for asynchronous IO, while providing a simpler programming model.

show abstract

Safe Commits for Transactional Featherweight Java

Tran¹,

Steffen²

2010

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Concurrency is a ubiquitous phenomenon in modern software ranging from distributed systems communicating over the Internet to communicating processes running on multi-core processors and multi-processors. Therefore modern programming languages offer ways to program concurrency effectively. Still, writing correct concurrent programs is notoriously difficult because of the complexity of possible interactions between concurrent processes and because concurrency-related errors are often subtle and hard to reproduce, especially for safety-critical applications. This thesis develops and formally investigates different static analysis methods for various concurrency-related problems in concurrent object-oriented programming languages to guarantee the absence of common concurrency-related errors, hence contribute to the quality of concurrent programs. My PhD period has been so far the most exciting, enjoyable, and memorable part of my life. I have learnt and grown so much both in knowledge and life. I was given a lot of opportunities to study and do research. I have met many interesting people and learnt so much from them. Now, at the end of my thesis time, first of all I would like to thank my main supervisor, Martin Steffen. I am greatly thankful for being his student. His broad and deep knowledge has opened a new world for me in the field of formal methods. His love and passion for research have influenced me a lot and kept me always motivated during 4 years of my PhD. It is known that during a PhD, anyone will at some point reach a low-point of motivation and enthusiasm. And I was not an exception. Sometimes I really wanted to give up, but when I looked at him, I said to myself "shame on me", because I have not seen any moment where he is bored with research, even when he is exhausted and could not move his body anymore but if one asks him a research question, he will suddenly become energetic again. From him, I have learnt things from basic to deep levels, how to appreciate one's own effort, how to be open-minded to new ideas, how to be more professional in working, how to think and do research independently. From him, I have learnt to be precise, concrete, and very honest when doing research. I could never expect anything better than that. As a leader of the group, Olaf Owe is a great supporter both in research and personal life. Olaf created all possibilities for me to access research resources like supporting me to go to conferences and schools where I met so many interesting people and my eyes were opened for new things. I always got back with so much passion for research. He always tried to share and find solutions for problems and difficulties I had to face from time to time. He is also the person who taught me how to keep a good balance between life and work. Also Einar Broch Johnsen has been very helpful and supportive for me. I benefited very much from his clear vision and direction in research, from his deep knowledge and his strict attitude in doing research and in writing papers (and in not tolerating ba...

show abstract

Automatic Mutual Exclusion and Atomicity Checks

Cited by 6 publications

References 18 publications

Effects for cooperable and serializable threads

Effects for cooperable and serializable threads

Ac

Safe Commits for Transactional Featherweight Java

Contact Info

Product

Resources

About