1,018 research outputs found
Permission-Based Separation Logic for Multithreaded Java Programs
This paper presents a program logic for reasoning about multithreaded
Java-like programs with dynamic thread creation, thread joining and reentrant
object monitors. The logic is based on concurrent separation logic. It is the
first detailed adaptation of concurrent separation logic to a multithreaded
Java-like language. The program logic associates a unique static access
permission with each heap location, ensuring exclusive write accesses and
ruling out data races. Concurrent reads are supported through fractional
permissions. Permissions can be transferred between threads upon thread
starting, thread joining, initial monitor entrancies and final monitor exits.
In order to distinguish between initial monitor entrancies and monitor
reentrancies, auxiliary variables keep track of multisets of currently held
monitors. Data abstraction and behavioral subtyping are facilitated through
abstract predicates, which are also used to represent monitor invariants,
preconditions for thread starting and postconditions for thread joining.
Value-parametrized types allow to conveniently capture common strong global
invariants, like static object ownership relations. The program logic is
presented for a model language with Java-like classes and interfaces, the
soundness of the program logic is proven, and a number of illustrative examples
are presented
Rigorous concurrency analysis of multithreaded programs
technical reportThis paper explores the practicality of conducting program analysis for multithreaded software using constraint solv- ing. By precisely defining the underlying memory consis- tency rules in addition to the intra-thread program seman- tics, our approach orders a unique advantage for program ver- ification | it provides an accurate and exhaustive coverage of all thread interleavings for any given memory model. We demonstrate how this can be achieved by formalizing sequen- tial consistency for a source language that supports control branches and a monitor-style mutual exclusion mechanism. We then discuss how to formulate programmer expectations as constraints and propose three concrete applications of this approach: execution validation, race detection, and atom- icity analysis. Finally, we describe the implementation of a formal analysis tool using constraint logic programming, with promising initial results for reasoning about small but non-trivial concurrent programs
Practical Fine-grained Privilege Separation in Multithreaded Applications
An inherent security limitation with the classic multithreaded programming
model is that all the threads share the same address space and, therefore, are
implicitly assumed to be mutually trusted. This assumption, however, does not
take into consideration of many modern multithreaded applications that involve
multiple principals which do not fully trust each other. It remains challenging
to retrofit the classic multithreaded programming model so that the security
and privilege separation in multi-principal applications can be resolved.
This paper proposes ARBITER, a run-time system and a set of security
primitives, aimed at fine-grained and data-centric privilege separation in
multithreaded applications. While enforcing effective isolation among
principals, ARBITER still allows flexible sharing and communication between
threads so that the multithreaded programming paradigm can be preserved. To
realize controlled sharing in a fine-grained manner, we created a novel
abstraction named ARBITER Secure Memory Segment (ASMS) and corresponding OS
support. Programmers express security policies by labeling data and principals
via ARBITER's API following a unified model. We ported a widely-used, in-memory
database application (memcached) to ARBITER system, changing only around 100
LOC. Experiments indicate that only an average runtime overhead of 5.6% is
induced to this security enhanced version of application
Preventing Atomicity Violations with Contracts
Software developers are expected to protect concurrent accesses to shared
regions of memory with some mutual exclusion primitive that ensures atomicity
properties to a sequence of program statements. This approach prevents data
races but may fail to provide all necessary correctness properties.The
composition of correlated atomic operations without further synchronization may
cause atomicity violations. Atomic violations may be avoided by grouping the
correlated atomic regions in a single larger atomic scope. Concurrent programs
are particularly prone to atomicity violations when they use services provided
by third party packages or modules, since the programmer may fail to identify
which services are correlated. In this paper we propose to use contracts for
concurrency, where the developer of a module writes a set of contract terms
that specify which methods are correlated and must be executed in the same
atomic scope. These contracts are then used to verify the correctness of the
main program with respect to the usage of the module(s). If a contract is well
defined and complete, and the main program respects it, then the program is
safe from atomicity violations with respect to that module. We also propose a
static analysis based methodology to verify contracts for concurrency that we
applied to some real-world software packages. The bug we found in Tomcat 6.0
was immediately acknowledged and corrected by its development team
Master of Science
thesisConcurrent programs are extremely important for efficiently programming future HPC systems. Large scientific programs may employ multiple processes or threads to run on HPC systems for days. Reliability is an essential requirement of existing concurrent programs. Therefore, verification of concurrent programs becomes increasingly important. Today we have two significant challenges in developing concurrent program verification tools: The first is scalability. Since new types of concurrent programs keep being created, verification tools need to scale to handle all these new types of programs. The second is providing formal coverage guarantee. Dynamic verification tools always face a huge schedule space. Both these capabilities must exist for testing programs that follow multiple concurrency models. Most current dynamic verification tools can only explore either thread level or process level schedules. Consequently, they fail to verify hybrid programs. Exploring mixed process and thread level schedules is not an ideal solution because the state space will grow exponentially in both levels. It is hard to systematically traverse these mixed schedules. Therefore, our approach is to determinize all concurrent APIs except one API whose schedules will then be explored. To improve search efficiency, we proposed a random-walk based heuristic algorithm. We observed many concurrent programs and concluded some common structures of them. Based on the existence of these structures, we can make dynamic verification tools focusing on specific regions and bypassing regions of less interest. We propose a random sampling of executions in the regions of less interest
Verifying Class Invariants in Concurrent Programs
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 Muller's ownership-based type system
- …