Ownership Types for Object Synchronisation

Lü, Yi; Potter, John; Xue, Jingling

doi:10.1007/978-3-642-35182-2_3

Cited by 3 publications

(2 citation statements)

References 36 publications

(61 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In general, these approaches rely on encapsulation, while our effect-based approach simply describes the effects of code and places no restriction on references. Our own work in [18] explores how to use ownership types to infer synchronisation requirement for structured parallelism. It does not consider explicit locks and does not use lock effects.…”

Section: Related Workmentioning

confidence: 99%

Structural Lock Correlation with Ownership Types

Lü

Potter

Xue

2013

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

Abstract. Concurrent object-oriented programming languages coordinate conflicting memory accesses through locking, which relies on programmer discipline and suffers from a lack of modularity and compiletime support. Programmers typically work with large libraries of code whose locking behaviours are not formally and precisely specified; thus understanding and writing concurrent programs is notoriously difficult and error-prone. This paper proposes structural lock correlation, a new model for establishing structural connections between locks and the memory locations they protect, in an ownership-based type and effect system. Structural lock correlation enables modular specification of locking. It offers a compiler-checkable lock abstraction with an enforceable contract at interface boundaries, leading to improved safety, understandability and composability of concurrent program components.

show abstract

Section: Related Workmentioning

confidence: 99%

Structural Lock Correlation with Ownership Types

Lü

Potter

Xue

2013

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…Object-oriented programming appears as the paradigm of choice to simplify concurrent programming [4,12,14,24,36], however, concurrent object-oriented programming (COOP) remains a difficult task. Many COOP languages are prone to what is called inheritance anomaly [25].…”

Section: Introductionmentioning

confidence: 99%

Why inheritance anomaly is not worth solving

Gramoli

Santosa²

2014

Proceedings of the 9th International Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Progra

View full text Add to dashboard Cite

Modern computers improve their predecessors with additional parallelism but require concurrent software to exploit it. Object-orientation is instrumental in simplifying sequential programming, however, in a concurrent setting, programmers adding new methods in a subclass typically have to modify the code of the superclass, which inhibits reuse, a problem known as inheritance anomaly. There have been much efforts by researchers in the last two decades to solve the problem by deriving anomaly-free languages. Yet, these proposals have not ended up as practical solutions, thus one may ask why.In this article, we investigate from a theoretical perspective if a solution of the problem would introduce extra code complexity. We model object behavior as a regular language, and show that freedom from inheritance anomaly necessitates a language where ensuring Liskov-Wing substitutability becomes a language containment problem, which in our modeling is PSPACE hard. This indicates that we cannot expect programmers to manually ensure that subtyping holds in an anomaly-free language. Anomaly freedom thus predictably leads to software bugs and we doubt the value of providing it.From the practical perspective, the problem is already solved. Inheritance anomaly is part of the general fragile base class problem of object-oriented programming, that arises due to code coupling in implementation inheritance. In modern software practice, the fragile base class problem is circumvented by interface abstraction to avoid implementation inheritance, and opting for composition as means for reuse. We discuss concurrent programming issues with composition for reuse.

show abstract