 is a possibility. The messaging schemadetermines the data available to each thread and vice versa. Thisapproach commits us to the location of data and of processing before wehave a good understanding of our new design's behavior. If we get itwrong, we have to start over. If the hardware environment changes, wehave to start over.
A “distributed object model” is an alternative to the threads andmessages approach. It brings all the benefits of object orientedprogramming and adds some benefits of its own. It divides applicationdata into discrete objects, allowing us to assign processing todifferent processors by locating objects on them.
A logical thread ofexecution visits whatever processor it needs to, in order to completeits work. The message passing layer of software is hidden inside remotemethod calls, which are semantically and syntactically identical tolocal method calls. The message passing layer can be automaticallygenerated from method signatures and any method in any class canpotentially be called remotely with a corresponding message. Localmethod calls incur no message passing overhead.
Consider what happens if we model an application in terms ofdistributedobjects instead of threads and messages. A detailed system model can bebuilt in terms of objects and methods without undue attention to objectlocation. (I say undue attention because object location must be bornein mind in key scenarios, but need not be completely specified at theoutset.)
A method call is a method call and we don't worry too much aboutwhether it's local or remote. The message passing layer is aconsequence of the classes and methods that are remotely accessed,whichin turn are consequences of object location.
Object location can bedecided late and changed easily. When it is decided or changed, themessage passing layer can be automatically generated, not hand written.So distributed object design methodology can reduce the cost andincrease the flexibility of a distributed application. Load balancingand ports to different hardware architectures can both be addressed byreassigning objects to different processors.
Distributed object middleware has been very successful intraditionaldistributed processing. CORBA, COM and Java RMI are well knownimplementations of the paradigm. But these technologies are designedforbig computers with big operating systems on slow networks. They focuslargely on defining and implementing interfaces between subsystems,witheach subsystem confined to an individual processor. Used carelessly,they give disappointing results.
The multicore environment demands distributed object middleware assmalland as fast as hand-optimized message passing. It must be highlytransparent to allow most objects to be remotely accessed, not just afew. Remote invocation needs to be like walking into another room, notvisiting another house. If this can be achieved, distributed objecttechnology can greatly reduce the difficulty, risk and cost of softwaredevelopment for asymmetric multiprocessors.
Dominic Herity is CTO of
For other articles about this topic, go to