D: A Language Framework for Distributed Programming

© Copyright 1997 Xerox Corporation. All rights reserved.

Table of Contents - Download complete thesis (~1M)
Abstract

Two of the most important issues in distributed systems are the synchronization of concurrent threads and the application-level data transfers between execution spaces. At the design level, addressing these issues typically requires analyzing the components under a different perspective than is required to analyze the functionality. Very often, it also involves analyzing several components at the same time, because of the way those two issues cross-cut the units of functionality. At the implementation level, existing programming languages fail to provide adequate support for programming in terms of these different and cross-cutting perspectives. The result is that the programming of synchronization and remote data transfers ends up being tangled throughout the components code in more or less arbitrary ways.

This thesis presents a language framework called D that untangles the implementation of synchronization schemes and remote data transfers from the implementation of the components. In the D framework there are three kinds of modules: (1) classes, which are used to implement functional components, and are clear of code dealing with the aspects; (2) coordinators, which concentrate the code for dealing with the thread synchronization aspect; and (3) portals which concentrate the code for dealing with the aspect of application-level data transfers over remote method invocations.

To support this separation, D provides two aspect-specific languages: COOL, for programming the coordinators, and RIDL, for programming the portals. COOL and RIDL were designed to address the specific needs of the two kinds of aspects. COOL and RIDL can be integrated with existing object-oriented languages like Java, with little or no modifications to that language. COOL’s coordinators and RIDL’s portals compose with the classes through the classes’ "aspect interfaces." Aspect interfaces are quite different than normal client interfaces but have some of the flavor of specialization interfaces.

D leads to programs whose modules are more focused and where the separation of concerns is more clear than it would be using traditional object-oriented languages. Often, D programs are smaller as well. D programs can be efficient ¾ the performance penalty of the framework is very low. In alpha-user experiments, programmers reported not only that they understood the aspect interfaces and the aspect languages well, but also that, having classes, coordinators and portals, helped them to focus on different issues at different times, and that this was of great help in the development of applications.

 

Table of Contents

1. Introduction

1.1. The Problem
1.2. The Approach
1.3. The Thesis
1.4. Synopsis of the Dissertation

2. Code Tangling

2.1. How Programs Become Tangled
2.1.1. Implementing the Functionality
2.1.2. Adding Synchronization Constraints
2.1.3. Providing for Remote Access
2.2. The Source of Tangling
2.3. Tangling and Programming Practices
2.3.1. Concurrency
2.3.1.1 Units of Synchronization
2.3.1.2 Splitting Classes
2.3.1.3 Splitting Locks
2.3.1.4 Coordination State
2.3.1.5 Coordination by Subclassing
2.3.2. Communication
2.3.2.1 Splitting Parts
2.3.2.2 Class Transformations
2.3.2.3 The Serializer Design Pattern
2.3.3. Summary
2.4. Tangling and Programming Languages
2.4.1. Basic Linguistic Support for Distributed Programming
2.4.1.1 Synchronization
2.4.1.2 Communication
2.4.2. Concurrency in Object-Oriented Languages
2.4.2.1 Orthogonal Approach
2.4.2.2 Full Integration
2.4.2.3 Separation of Coordination and Functionality
2.4.3. Communication in Object-Oriented Languages
2.4.3.1 Orthogonal Approach
2.4.3.2 Full Integration
2.4.3.3 Hybrid Approaches
2.5. Final Remarks

3. The D Framework

3.1. Design Principles
3.1.1. Separation of Concerns: Identification of Aspects
3.1.2. Control over the Separation
3.1.3. Integration with Existing Languages
3.2. Specification of the Languages
3.2.1. Conventions and Notation
3.2.2. The Component Language
3.2.2.1 Types, Values and Variables
3.2.2.2 Classes
3.2.2.3 Creation of Threads
3.2.2.4 The Meaning of Objects, Threads and Execution Spaces
3.2.3. The Visible Elements of Components
3.2.4. The Coordination Aspect Language
3.2.4.1 Visible Elements of Classes
3.2.4.2 Coordinator Declaration
3.2.4.3 Coordinator Body
3.2.4.4 Condition Variables
3.2.4.5 Ordinary Variables
3.2.4.6 Self-Exclusive Methods
3.2.4.7 Mutual Exclusion Declarations
3.2.4.8 Method Managers
3.2.4.9 Guarded Suspension
3.2.4.10 On Entry and On Exit Statements
3.2.4.11 Some Examples of Coordinators
3.2.5. The Remote Interface Aspect Language
3.2.5.1 Visible Elements of Classes
3.2.5.2 Portal Declaration
3.2.5.3 Portal Body
3.2.5.4 Remote Operations
3.2.5.5 Object Transfer Specifications
3.2.5.6 Type Transfer Specifications
3.2.5.7 Passing Global References
3.2.5.8 Passing Copies
3.2.5.9 Copying Directives
3.2.5.10 Classes that Must Have a Portal
3.2.5.11 Some Examples of Portals
3.2.6. Interaction between Aspects and Class Inheritance
3.3. Design Decisions and Alternatives
3.3.1. General
3.3.1.1 On Modules, Components, Aspects and Interfaces
3.3.1.2 The Need for Special Abstractions and Composition Mechanisms
3.3.1.3 Who Drives Who
3.3.2. The Component Language
3.3.2.1 Class-based Language vs. Prototype-based Language
3.3.2.2 Uniform Reference Semantics
3.3.2.3 Threads
3.3.2.4 The Default Synchronization
3.3.2.5 The Default Communication
3.3.3. COOL
3.3.3.1 Coordination: Classes vs. Abstract Method Sets
3.3.3.2 Granularity of Synchronization
3.3.3.3 Synchronization: Local vs. Distributed
3.3.3.4 Exclusion Constraints
3.3.3.5 Assignments
3.3.3.6 Current Limitations
3.3.4. RIDL
3.3.4.1 Remote Interaction: Classes vs. Abstract Types
3.3.4.2 Granularity of Remote Interaction
3.3.4.3 On the Semantics of gref
3.3.4.4 The Copying Directives
3.3.4.5 The Missing Parts
3.3.4.6 Current Limitations
3.4. Final Remarks

4. Implementation

4.1. Engineering the Implementation Space
4.2. Target Architectures for Implementing COOL
4.2.1. Coordinator Objects
4.2.2. Mutual Exclusion and Re-entrance
4.2.3. Requires Clause
4.2.4. Access to Variables of the Coordinated Objects
4.2.5. Per Class Coordination
4.2.6. Inheritance of Aspect Code
4.2.7. Examples
4.2.7.1 Simplest Case: one class, per_object coordination, no inheritance
4.2.7.2 Inheritance of Coordination
4.2.7.3 Overriding of Coordination
4.2.7.4 Multi-class Coordination (per_class)
4.3. Target Architectures for Implementing RIDL
4.3.1. Run-time Architecture
4.3.1.1 Application-level Proxies for D’s Remote Objects
4.3.1.2 Portal Objects and their Proxies
4.3.1.3 Traversals and Traversal Classes
4.3.2. The Name Service
4.3.3. RIDL’s Data Transfer Protocols
4.3.3.1 Passing Primitive Data
4.3.3.2 Passing Global References
4.3.3.3 Passing Copies
4.3.4. Examples
4.3.4.1 Arguments of Primitive Types and gref
4.3.4.2 Passing Copies
4.3.4.3 Inheritance of Portals
4.4. Integrating COOL and RIDL
4.5. Summary

5. Validation

5.1. Case-Studies
5.1.1. The Bounded Buffer
5.1.2. The Dinning Philosophers
5.1.3. The Shape
5.1.4. Concurrent Matrix Multiplication
5.1.5. Concurrent Graph Traversal
5.1.6. Assembly Line
5.1.7. Distributed BookLocator/PrintService
5.1.8. Distributed Text Editor
5.1.9. Distributed Document Service
5.1.10. Message Queue
5.1.11. Analysis
5.1.11.1 LOC
5.1.11.2 Aspectual Bloat
5.1.11.3 Methods Affected by Aspect Code
5.1.11.4 Tangling Ratio
5.1.11.5 Analysis of the Results
5.2. Performance
5.3. Preliminary User-Studies
5.3.1. The Summer Experiment
5.3.2. The Applications
5.3.2.1 The Space War
5.3.2.2 The Space War - Java and Sockets
5.3.2.3 Distributed Library System
5.3.3. Alpha-Users’ Reports
5.4. Final Remarks

6. Conclusions

6.1. Summary
6.2. Contributions
6.3. Future Work
6.4. Conclusion

Appendix A. Syntax
Appendix B. DJ Primer
Appendix C. The Aspect Weaver
Appendix D. DJ Library Classes
Appendix E. User Reports

 
 Bibliography