Capsule-oriented programming

Explicit concurrency should be abolished from all higher-level programming languages (i.e. everything except - perhaps- plain machine code.). Dijkstra [1] (paraphrased). A promising class of concurrency abstractions replaces explicit concurrency mechanisms with a single linguistic mechanism that combines state and control and uses asynchronous messages for communications, e.g. active objects or actors, but that doesn\u27t remove the hurdle of understanding non-local control transfer. What if the programming model enabled programmers to simply do what they do best, that is, to describe a system in terms of its modular structure and write sequential code to implement the operations of those modules and handles details of concurrency? In a recently sponsored NSF project we are developing such a model that we call capsule-oriented programming and its realization in the Panini project. This model favors modularity over explicit concurrency, encourages concurrency correctness by construction, and exploits modular structure of programs to expose implicit concurrency

Object Technology for Ambient Intelligence : Workshop Reader for OT4Aml at ECOOP 2007

This reader comprises the submissions to the third workshop on object-technology for Ambient Intelligence and Pervasive Computing held at ECOOP 2007

Declarative Scheduling for Active Objects

International audienceActive objects are programming constructs that abstract dis- tribution and help to handle concurrency. In this paper, we extend the multiactive object programming model to offer a priority specification mechanism. This mechanism allows programmers to have control on the scheduling of requests. The priority representation is based on a dependency graph which makes it very convenient to use. This article shows how to use this mechanism from the programmer side, and exposes the main properties of the dependency graph. The software architecture of our implementation is also presented, as it can be applied to various scheduling systems. Finally, we validate our approach through a microbenchmark that shows that the overhead of our priority representation is rather low. On the whole, we provide a general pattern to introduce a prioritized scheduling in active objects or in any other con- current systems. The resulting framework is shown to be fine-grained, user-friendly, and efficient

A Type-Safe Model of Adaptive Object Groups

Services are autonomous, self-describing, technology-neutral software units that can be described, published, discovered, and composed into software applications at runtime. Designing software services and composing services in order to form applications or composite services requires abstractions beyond those found in typical object-oriented programming languages. This paper explores service-oriented abstractions such as service adaptation, discovery, and querying in an object-oriented setting. We develop a formal model of adaptive object-oriented groups which offer services to their environment. These groups fit directly into the object-oriented paradigm in the sense that they can be dynamically created, they have an identity, and they can receive method calls. In contrast to objects, groups are not used for structuring code. A group exports its services through interfaces and relies on objects to implement these services. Objects may join or leave different groups. Groups may dynamically export new interfaces, they support service discovery, and they can be queried at runtime for the interfaces they support. We define an operational semantics and a static type system for this model of adaptive object groups, and show that well-typed programs do not cause method-not-understood errors at runtime.Comment: In Proceedings FOCLASA 2012, arXiv:1208.432

First Class Futures: Specification and implementation of Update Strategies

International audienceA natural way to benefit from distribution is via asynchronous invocations to methods or services. Upon invocation, a request is enqueued at the destination side and the caller can continue its execution. But a question remains: “what if one wants to manipulate the result of an asynchronous invocation?” First-class futures provide a transparent and easy-to-program answer: a future acts as the placeholder for the result of an asynchronous invocation and can be safely transmitted between processes while its result is not needed. Synchronization occurs automatically upon an access to the result. As references to futures disseminate, a strategy is necessary to propagate the result of each request to the processes that need it. This paper studies the efficient transmission of results: it presents three strategies in a semi-formal manner, providing experimental results highlighting their benefits and drawbacks

A Study of Concurrency Bugs and Advanced Development Support for Actor-based Programs

The actor model is an attractive foundation for developing concurrent applications because actors are isolated concurrent entities that communicate through asynchronous messages and do not share state. Thereby, they avoid concurrency bugs such as data races, but are not immune to concurrency bugs in general. This study taxonomizes concurrency bugs in actor-based programs reported in literature. Furthermore, it analyzes the bugs to identify the patterns causing them as well as their observable behavior. Based on this taxonomy, we further analyze the literature and find that current approaches to static analysis and testing focus on communication deadlocks and message protocol violations. However, they do not provide solutions to identify livelocks and behavioral deadlocks. The insights obtained in this study can be used to improve debugging support for actor-based programs with new debugging techniques to identify the root cause of complex concurrency bugs.Comment: - Submitted for review - Removed section 6 "Research Roadmap for Debuggers", its content was summarized in the Future Work section - Added references for section 1, section 3, section 4.3 and section 5.1 - Updated citation

Reusing and Composing Tests with Traits

International audienceSingle inheritance often forces developers to duplicate code and logic. This widely recognized situation affects both business code and tests. In a large and complex application whose classes implement many groups of methods (protocols), duplication may also follow the application's idiosyncrasies, making it difficult to specify, maintain, and reuse tests. The research questions we faced are (i) how can we reuse test specifications across and within complex inheritance hierarchies, especially in presence of orthogonal protocols; (ii) how can we test interface behavior in a modular way; (iii) how far can we reuse and parametrize composable tests. In this paper, we compose tests out of separately specified behavioral units of reuse —traits. We propose test traits, where: (i) specific test cases are composed from independent specifications; (ii) executable behavior specifications may be reused orthogonally to the class hierarchy under test; (iii) test fixtures are external to the test specifications, thus are easier to specialize. Traits have been successfully applied to test two large and critical class libraries in Pharo, a new Smalltalk dialect based on Squeak, but are applicable to other languages with traits

First Class Futures: Specification and implementation of Update Strategies

International audienceA natural way to benefit from distribution is via asynchronous invocations to methods or services. Upon invocation, a request is enqueued at the destination side and the caller can continue its execution. But a question remains: “what if one wants to manipulate the result of an asynchronous invocation?” First-class futures provide a transparent and easy-to-program answer: a future acts as the placeholder for the result of an asynchronous invocation and can be safely transmitted between processes while its result is not needed. Synchronization occurs automatically upon an access to the result. As references to futures disseminate, a strategy is necessary to propagate the result of each request to the processes that need it. This paper studies the efficient transmission of results: it presents three strategies in a semi-formal manner, providing experimental results highlighting their benefits and drawbacks

First Class Futures: a Study of Update Strategies

Futures enable an efficient and easy to use programming paradigm for distributed applications. A natural way to benefit from distribution is to perform asynchronous invocations to methods or services. Upon invocation, a request is en-queued at the destination side and the caller can continue its execution. But a question remains: ``what if one wants to manipulate the result of an asynchronous invocation?'' First-class futures provide a transparent and easy-to-program answer: a future acts as the placeholder for the result of an asynchronous invocation and can be safely transmitted between processes while its result is not needed. Synchronization occurs automatically upon an access requiring the result. As references to futures disseminate, a strategy is necessary to propagate the result of each request to the processes that need it. This report studies the efficient transmission of results: it presents three main strategies in a semi-formal manner, and provides a cost analysis with some experiments to determine the efficiency of each strategy