From: wtwolfe@hubcap.clemson.edu (Bill Wolfe)
Subject: Integrating concurrent & O-O programming
Date: 15 Nov 89 19:30:10 GMT [thread overview]
Message-ID: <7062@hubcap.clemson.edu> (raw)
[This is taken from Object-Oriented Development, edited by Dennis
Tsichritais, Centre Universitaire d' Informatique, Universite'
de Geneve, a non-copyrighted summarization of research activity;
the specific paper is "Concurrency Issues in Object-Oriented
Programming, by M. Papathomas, page 207. It describes ideas which
are relevant to the current Ada 9X language revision process.]
Although the integration of object-oriented and concurrent programming
is promising for the development of software for such applications, the
design of programming languages that keep up with this promise is a
difficult task. The concurrent features of a language may interfere
with its object-oriented features making them hard to integrate in a
single language or cause many of their benefits to be lost. For instance,
encapsulation in sequential object-oriented programming languages protects
the internal state of objects from arbitrary manipulation and ensures its
consistency. If concurrent execution is introduced in a language
independently of objects it will compromise encapsulation, since concurrent
execution of the operations of objects may violate the consistency of
their internal state...
...consider the interference that occurs between class inheritance
and encapsulation when subclasses are allowed to access freely the
instance variables of the parent class [Sny86]. In this case we may
say that support for inheritance diminishes the degree of encapsulation
that was achieved without inheritance...
...we identify two categories of COOPLs [Concurrent Object-Oriented
Programming Languages]. We will call _orthogonal_ the category of
languages where objects are unrelated to concurrency, and _non-orthogonal_
the category of languages where objects have some predefined properties
concerning concurrency... According to whether or not a language supports
objects of different kinds, we will further subdivide the category of
non-orthogonal languages into the _non-uniform_ and _uniform_ categories.
Languages in the uniform category support only one kind of object whereas
language in the non-uniform category split the object world into two kinds
of objects: those that serialize the execution of their operations and
those that do not. Concurrent execution may be expressed by explicitly
creating new threads of control, independently of objects, that communicate
and synchronize by invoking the operations of shared objects. Another
approach is to consider objects as active entities and express concurrent
execution and synchronization by the creation of objects and their
interaction. We use these two approaches to subdivide the uniform category
into the categories _integrated_ and _non-integrated_. For languages in
the integrated category concurrent execution is expressed by interaction
of objects whereas in the non-integrated category another concept like a
process or activity is used for expressing concurrent execution...
The non-orthogonal class has the advantage of preventing the problems
that could occur by using "unprotected" objects in [a] concurrent
environment. Objects of sequential nature may be implemented in
much the same way as in sequential languages. The mutually exclusive
execution of the object's operations is handled automatically by the
language. The distinction between different kinds of objects
characterizing the non-uniform category presents some disadvantages
compared to the uniform one. The programmer has to decide in advance
if a certain object should be of the "protected" or "unprotected" type.
Type hierarchies... are typically kept disjoint... introducing a certain
redundancy in the class hierarchy... The integrated approach has the
advantage that concurrent applications are structured in terms of objects
which are the units of concurrent execution. The communication and
synchronization of objects is expressed at the object interface which
is clearly defined...
Support for mechanisms similar to data abstraction in COOPLs is even
more badly needed than in sequential languages but also is hard to
provide. Ideally the data abstraction mechanism provided by COOPLs
should separate the aspects of concurrent execution relevant to an
object's implementation from the concurrent behavior of the abstraction...
For reaching such goals we would need a way for describing the externally
observable behavior of objects, be able to and automatically check that
the realization of objects satisfies the specifications. This goal seem[s]
unreachable in the near future. It would be more reasonable to provide
compromises by designing abstraction mechanisms that capture more
information about the behavior of active objects than abstract data
types. A parallel to this approach may be drawn with the way ADTs are
used in sequential programming languages and the use of assertions
instead of supporting algebraic specifications and automatic verification
of programs...
Concurrency is not orthogonal to other aspects of object-oriented
programming. Although several object-oriented languages that provide
support for concurrent programming have been designed and implemented
their concurrent features interfere with their object-oriented features.
Furthermore, the approaches taken for concurrency may have a considerable
impact on the structure of applications in a way that is contrary to the
principles underlying object-oriented programming...
Although abstraction mechanisms conveying more information than ADTs
about the behavior of objects are badly needed in COOPLs, very little
has been done in this direction by COOPLs. This may be explained by
the fact that [there] does not seem to exist a consensus on formal
models for the specification of the behavior of concurrent systems
that would provide a basis for development of abstraction mechanisms
that would extend the data abstraction mechanism to concurrent languages...
We believe that the development of type systems for COOPLs is intimately
related to the development of formal models for the specification of the
time-dependent behavior of objects, and the development of abstraction
mechanisms that will extend data abstraction to include more information
about such behavior.
Exception handling mechanisms are even more important in concurrent
systems than they are in sequential ones. The failure of a process
should not entail the failure of the whole systems since other processes
may be able to proceed.
Persistence is useful for the development of a host of applications.
Providing support for persistence in a programming language frees the
application programmer from the burden of explicitly managing persistence
by using files. The atomicity properties of transactions are especially
attractive in a system that has to deal with long lived persistent data.
Although persistence on its own does not seem to interfere with concurrency
features of a language it is not the same concerning transactions. The
noninterference property of transactions seems contrary to the close
interaction and communication of processes that characterizes concurrent
programming and the independence of objects promoted by object-oriented
programming.
The full integration of concurrency with all the other aspects of
object-oriented programming presents several problems that deserve
more attention... further work is required for gaining more insight
in the nature of these problems and for developing languages that
provide satisfactory solutions.
next reply other threads:[~1989-11-15 19:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1989-11-15 19:30 Bill Wolfe [this message]
1989-11-21 4:09 ` Integrating concurrent & O-O programming Tim Atkins
1989-11-22 22:08 ` 3929
1989-11-22 22:37 ` Dan Weinreb
1989-11-23 2:52 ` Ziaul Masum Hasan
1989-11-23 9:46 ` Re^2: " NIERSTRASZ Oscar
1989-11-23 16:18 ` BJORNERSTEDT Anders
1989-11-26 14:04 ` Markku Sakkinen
1989-11-23 14:56 ` BJORNERSTEDT Anders
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox