An Event-Based Structural Operational Semantics of Multi-threaded Java

Abstract

A structural operational semantics of a significant sublanguage of Java is presented, including the running and stopping of threads, thread interaction via shared memory, synchronization by monitoring and notification, and sequential control mechanisms such as exception handling and return statements. The operational semantics is parametric in the notion of "event space" [6], which formalizes the rules that threads and memory must obey in their interaction. Different computational models are obtained by modifying the well-formedness conditions on event spaces while leaving the operational rules untouched. In particular, we implement the prescient stores described in [10, §17.8] which allow certain intermediate code optimizations, and prove that such stores do not affect the semantics of properly synchronized programs.

Verification for Java’s Reentrant Multithreading Concept

“…Formal semantics of Java, including multithreaded execution, and its virtual machine in terms of abstract state machines is given in [29]. A structural operational semantics of multithreaded Java can be found in [12].…”

“…[4,29,12]). The research concerning Java's proof theory mainly concentrated on various aspects of sequential sublanguages (see e.g.…”

Formal Modeling of a Slicing Algorithm for Java Event Spaces in PVS

“…through (iv.) of this definition rely on the formalization of the JMM [2,10]. For instance, Item (ii.)…”

“…Java event spaces [2,10] are partial orders of the actions performed by the main memory and the threads of a multi-threaded Java program. In previous work [1] we showed how classical slicing techniques can be employed to reduce the size of Java event spaces.…”

Verification of Concurrent Objects with Asynchronous Method Calls

“…The interference problem related to shared variables reemerges when threads operate concurrently in the same object, which happens with nonserialized methods in Java. Reasoning about programs in this setting is a highly complex matter [1,10]: Safety is by convention rather than by language design [9]. Verification considerations therefore suggest that all methods should be serialized as done in e.g.…”