A type safe state abstraction for coordination in Java-like languages

The state of a concurrent object, intended as some abstraction over the values of the fields of the object, usually determines its coordination behavior. Therefore, state is always in the programmer’s mind, even though implicitly. We suggest a feature for J ava -like languages, which makes the state...

Full description

Saved in:
Bibliographic Details
Published inActa informatica Vol. 45; no. 7-8; pp. 479 - 536
Main Authors Damiani, Ferruccio, Giachino, Elena, Giannini, Paola, Drossopoulou, Sophia
Format Journal Article
LanguageEnglish
Published Berlin/Heidelberg Springer-Verlag 01.12.2008
Springer
Springer Nature B.V
Subjects
Online AccessGet full text

Cover

Loading…
More Information
Summary:The state of a concurrent object, intended as some abstraction over the values of the fields of the object, usually determines its coordination behavior. Therefore, state is always in the programmer’s mind, even though implicitly. We suggest a feature for J ava -like languages, which makes the state of a concurrent object explicit and supports the expression of the object’s behavior depending on the state it is currently in. Namely, an object will be in one of the states declared in its class. The state determines the presence of fields and methods. State transition statements explicitly change the state of an object, and thus change the availability of fields and methods. When a thread calls a method which is declared in the object’s class but absent from its current state, it waits, until the state of the object changes to a state which does contain that method. This directly expresses coordination. We claim that this feature makes it easier to understand and develop concurrent programs, and substantiate our claim through the discussion of some popular examples of concurrent programs written using this feature.We develop a type and effect system, which guarantees that, during execution of a method invoked on a concurrent object : (1) No attempt will be made to access fields not available in the current state of , and (2) No method invoked on a receiver (syntactically) different from may cause the invocation of a method on . The latter guarantee helps to enforce the former and prevents a family of accidental violations of the intended coordination protocol.
Bibliography:ObjectType-Article-2
SourceType-Scholarly Journals-1
ObjectType-Feature-1
content type line 23
ISSN:0001-5903
1432-0525
DOI:10.1007/s00236-008-0079-y