Verification for Java’s Reentrant Multithreading Concept

Abstract

Abstract.Besides the features of a class-based object-oriented language, Java integrates concurrency via its thread-classes, allowing for a multithreaded flow of control. The concurrency model offers coordination via lock-synchronization, and communication by synchronous message passing, including re-entrant method calls, and by instance variables shared among threads. To reason about multithreaded programs, we introduce in this paper an assertional proof method for JavaMT ("Multi-Threaded Java"), a small concurrent sublanguage of Java, covering the mentioned concurrency issues as well as the object-based core of Java, i.e., object creation, side effects, and aliasing, but leaving aside inheritance and subtyping.

A Relational Model for Object-Oriented Designs

“…Alternatively, one can also use temporal logic, such as [3], for the specification and verification of multithreading Java-like programs. However, we would like to deal with concurrency at a higher level when we extend this model for componentbased software development [17,16].…”

Adapting Active Objects to Multicore Architectures

“…On the other hand, it is rather hard to deal both with the application logic and with the clearly orthogonal task of concurrent synchronization at the same time. Even if concurrent code is supposed to improve the performance of an application, if it is unwisely written it can introduce race-conditions, which make development and testing difficult [10], [11].…”

Verification of Concurrent Objects with Asynchronous Method Calls

“…Much recent work has addressed reasoning about sequential object-oriented languages [18,27,28], covering various aspects such as inheritance, subtyping, and dynamic binding. However, reasoning about multithreaded objectoriented languages is more challenging [1,10]. For example, the approach of [1] uses a global cooperation test to deal with object communication.…”

“…However, reasoning about multithreaded objectoriented languages is more challenging [1,10]. For example, the approach of [1] uses a global cooperation test to deal with object communication. In addition, interference freedom must be proved since several threads may execute concurrently in the same object.…”

“…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.…”