High‐level data races

Artho, Cyrille; Havelund, Klaus; Biere, Armin

doi:10.1002/stvr.281

Cited by 145 publications

(114 citation statements)

References 19 publications

Supporting

Mentioning

114

Contrasting

Order By: Relevance

“…In [6], the problem of violation of atomicity of operations over multiple variables is referred to as a high-level data race. In the work, all synchronised blocks (i.e., blocks of code guarded by the synchronised statement) are considered to form atomic sections.…”

Section: Detection Of Atomicity Violationmentioning

confidence: 99%

A Uniform Classification of Common Concurrency Errors

Fiedor

Bohuslav

ena

et al. 2012

Computer Aided Systems Theory – EUROCAST 2011

View full text Add to dashboard Cite

Abstract. Nowadays, multi-threaded programs are quite common and so are concurrency errors. Many works devoted to detection of concurrency errors have been published in recent years and many of them presented definitions of concurrency errors that the proposed algorithms are able to handle. These definitions are usually expressed in different terms suitable for a description of the particular considered algorithms and they surprisingly often differ from each other in the meaning they assign to particular errors. To help understanding the errors and developing techniques for detecting them, this report strives to provide a uniform taxonomy of concurrency errors common in current programs, with a stress on those written in Java, together with a brief overview of techniques so far proposed for detecting such errors.

show abstract

Section: Detection Of Atomicity Violationmentioning

confidence: 99%

A Uniform Classification of Common Concurrency Errors

Fiedor

Bohuslav

ena

et al. 2012

Computer Aided Systems Theory – EUROCAST 2011

View full text Add to dashboard Cite

show abstract

“…High-level data races may take the form of view inconsistency [24], where memory is read inconsistently, as well as stale-value errors [25], where a value read from a shared variable is used beyond the synchronization scope in which it was acquired. Our problematic interleaving scenarios capture these forms of high-level data races, as well as several others, in one framework.…”

Section: Related Workmentioning

confidence: 99%

Finding concurrency-related bugs using random isolation

Kidd

Reps

Dolby

et al. 2011

Int J Softw Tools Technol Transfer

View full text Add to dashboard Cite

Abstract. This paper describes the methods used in Empire, a tool to detect concurrency-related bugs, namely atomic-set serializability violations in Java programs. The correctness criterion is based on atomic sets of memory locations, which share a consistency property, and units of work, which preserve consistency when executed sequentially. Empire checks that, for each atomic set, its units of work are serializable. This notion subsumes data races (single-location atomic sets), and serializability (all locations in one atomic set).To obtain a sound, finite model of locking behavior for use in Empire, we devised a new abstraction principle, random isolation, which allows strong updates to be performed on the abstract counterpart of each randomly-isolated object. This permits Empire to track the status of a Java lock, even for programs that use an unbounded number of locks. The advantage of random isolation is that properties proved about a randomly-isolated object can be generalized to all objects allocated at the same site. We ran Empire on eight programs from the ConTest benchmark suite, for which Empire detected numerous violations.

show abstract

“…For example, when the field x in the invariant above is updated, any other thread might observe this change and the broken invariant. This problem is sometimes called a high-level data race [2]. Therefore, this paper defines an approach to define validity of class invariants in a multithreaded setting.…”

Section: Introductionmentioning

confidence: 99%

Verifying Class Invariants in Concurrent Programs

Zaharieva-Stojanovski

Huisman

2014

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Abstract. Class invariants are a highly useful feature for the verification of object-oriented programs, because they can be used to capture all valid object states. In a sequential program setting, the validity of class invariants is typically described in terms of a visible state semantics, i.e., invariants only have to hold whenever a method begins or ends execution, and they may be broken inside a method body. However, in a concurrent setting, this restriction is no longer usable, because due to thread interleavings, any program state is potentially a visible state.In this paper we present a new approach for reasoning about class invariants in multithreaded programs. We allow a thread to explicitly break an invariant at specific program locations, while ensuring that no other thread can observe the broken invariant. We develop our technique in a permission-based separation logic environment. However, we deviate from separation logic's standard rules and allow a class invariant to express properties over shared memory locations (the invariant footprint), independently of the permissions on these locations. In this way, a thread may break or reestablish an invariant without holding permissions to all locations in its footprint. To enable modular verification, we adopt the restrictions of Müller's ownership-based type system.

show abstract

High‐level data races

Cited by 145 publications

References 19 publications

A Uniform Classification of Common Concurrency Errors

A Uniform Classification of Common Concurrency Errors

Finding concurrency-related bugs using random isolation

Verifying Class Invariants in Concurrent Programs

Contact Info

Product

Resources

About