In the age of the world-wide web and mobile computing, programming communication-centric software is essential. Thus, programmers and program designers are exposed to new levels of complexity, such as ensuring the correct composition of communication behaviours and guaranteeing deadlock-freedom
of their protocols.
This paper proposes the language Ldoos, a simple distributed object-oriented language augmented with session communication primitives and types. Ldoos provides a flexible object-oriented programming style for structural interaction protocols by prescribing channel usages within signatures of distributed classes.
We develop a typing system for Ldoos and prove its soundness with respect to the operational semantics. We also show that in a well-typed Ldoos program, there will never be a connection error, a communication error, nor an incorrect completion between server-client interactions. These results demonstrate that a consistent integration of object-oriented language features and session types offers a compositional method to statically check safety of communication protocols.
Tuesday, February 12, 2008
A Distributed Object-Oriented Language with Session Types
Abstract:
Wednesday, January 02, 2008
Ticket-passing style?
Upon further reflection, I think it does not make sense for application programmer to control CPU distribution down to the ticks.
This would over-specify the scheduling requirements, which often are quite lax.
Presence of multiple physical processors makes the situation even worse.
What probably makes sense is to allow the application developer to explicitly track the separate computation parts, assigning to them various properties, and enabling two-way reflective link between the programmer and the real scheduler.
Think of this as a task management system, e.g., Jira.
Persons acting in one role can create tasks, manage their dependencies, deadlines, estimates and priorities, while persons in another role execute the project making sure the tasks are completed at a satisfactory time.
The first role is like one for the application developer, the second one is for the scheduler of the language's runtime.
This would over-specify the scheduling requirements, which often are quite lax.
Presence of multiple physical processors makes the situation even worse.
What probably makes sense is to allow the application developer to explicitly track the separate computation parts, assigning to them various properties, and enabling two-way reflective link between the programmer and the real scheduler.
Think of this as a task management system, e.g., Jira.
Persons acting in one role can create tasks, manage their dependencies, deadlines, estimates and priorities, while persons in another role execute the project making sure the tasks are completed at a satisfactory time.
The first role is like one for the application developer, the second one is for the scheduler of the language's runtime.
Subscribe to:
Posts (Atom)
