features matrixintro pageEditor's note: the following introductory text has been suppliedby the Editor.
Object models can be distinguished on the basis of the interaction primitivesthey support. These interact with the degree of concurrency that the modelintends to support, and with any internal process structure that objectsin the model may have. The basic means of information interchange in anobject model is the message or request. An interaction between objectsinvolves at least one object sending a message to at least a second objectthat receives it. There may be more than one construct provided to sendor receive messages in a given model. Another consideration for each ofthe constructs is whether the construct is synchronous or asynchronous.A synchronous construct is one that causes the sending object to blockuntil some other message-related event occurs. An asynchronous constructis one that permits the sending object to continue processing once theconstruct is executed locally. This choice reflects issues of synchronizationas well as those of pure information exchange. These two dimensions givefour possible choices for constructs: blocking send, non-blocking send,blocking receive, and non-blocking receive. All of these have been usedin one way or another in various models. Language designs based on theseapproaches usually include variations and/or composite constructs thatallow aggregate actions to be specified in terms of the set of interactionprimitives supported. Examples include such concepts as hot links,pipes, as well as the transaction concept used in databasesystems and some programming languages. [Man89]
OMG CORBA IDL
CORBA provides a layer of abstraction above the communications layer,thus shielding clients from needing to know about the underlying communicationsmechanisms or where in the network the target object resides.
ODMG
The model assumes operations are executed sequentially, although itdoes not preclude concurrent or parallel operations.
The model supports nested transactions, where the commit of a nestedtransaction is dependent on the containing parent transaction's commit.Type Transaction defines operations to begin, commit, abort and checkpointa transaction. A transaction obtains standard read and write locks withpessimistic concurrency control.
Management Information Model
Not applicable.
OOCOBOL
The programming model for OO COBOL is synchronous.
Smalltalk
All communications within Smalltalk occur through messages between objectsand most Smalltalk implementations support a form of concurrency. For example,Smalltalk-80 provides for multiple independent processes, and semaphoresprovide the common mechanism for synchronizing the independent processes.
Eiffel
Currently not applicable, however an implementation for concurrencyin Eiffel is being developed and may be released in future versions.
Emerald
Emerald supports concurrency, in the form of active objects.An active object contains a process that is started after the object isinitialized, and executes in parallel with invocations of the object'soperations, and with the executions of other active objects. This processcontinues to execute its specified instructions until it terminates. AnEmerald process represents an independent thread of control. New threadsmay be created dynamically by creating new objects.
In Emerald, operation invocation is synchronous. Thus, a thread of controlcan be thought of as passing through other objects when it invokes operationson those objects. This means that there can be multiple simultaneous invocationsof an operation in the same object. Each such invocation can proceed independently.
Emerald uses monitors to regulate access to local state thatis shared by the object's operations and process. Synchronization is achievedusing system-defined condition objects [Hoa74]. [RTLB+91]
The following example illustrates various aspects of Emerald with asimple implementation of a clock. The objects in the example are createdusing Emerald object constructors, denoted by the keyword object(see entry under 5. Encapsulation for a description of object constructors).The clock object uses a simple internal representation (theTime)that is protected by a monitor and can be manipulated by several monitoredoperations. The internal representation is constantly updated by the clockobject's process, which synchronizes with a timing pulse provided by thesystem object. The operations for converting between the internal and externalrepresentations are defined outside the monitor, thus allowing multiplesimultaneous invocations of them to proceed concurrently. The Systemobject demonstrates a simple use of Emerald condition objects to providebuffering of timing pulses. [RTLB+91]
const Clock <- object C export getTimeOfDay, setTimeOfDay monitor var theTime: Integer <- 0 operation IncTime theTime <- theTime + 1 end IncTime function getTime -> [r: Integer] r <- theTime end getTime
operation setTime [r: Integer] theTime <- r end setTime end monitor operation setTimeOfDay[newTime: String] var t: Integer % store newTime in some internal form setTime[t] end setTimeOfDay
operation getTimeOfDay -> [currentTime: String] var t: Integer <- getTime % return the String form of t end getTimeOfDay process loop System.Tock IncTime end loop end process
end Cconst System <- object S monitor const timing <- Condition.Create % Tick is invoked by a hardware clock
operation Tick signal timing end Tick operation Tock wait timing end Tock end monitor end S
System Object Model (SOM)
Since SOM is a basic mechanism, its run-time model is one where an operationoccurs on a single thread within a single process. However, SOM code permitsconcurrent execution by multiple threads on systems where SOM supportsthe underlying threads model, therefore, multi-threaded programs can usemutual exclusion mechanisms to serialize updates to SOM objects with confidencethat critical sections in SOM are thread safe.
Complex object interactions that need to span process boundaries canbe constructed on SOM using standard inter-process communication facilitiesprovided by the underlying system. No serialization code is necessary ifprogramming in a single thread , single process model.
A class library based on SOM is used to provide SOM with distributedaccess to remote SOM objects.
OLE Component Object Model
The programming model for Windows Objects is synchronous, based on a"Lightweight Remote Procedure Call" (lightweight because, atleast at the moment, the calls are not really remote; they are all madeon one machine). Further development will allow the lightweight RPC tobe replaced by genuine (distributed) RPC. features matrixintro page