After decades of anticipation, multiprocessors are becoming a fact oflife for most software engineers, especially in embedded systems.Symmetric multiprocessors which use a number of identical processors,one operating system and a shared memory are relatively easy toprogram,because we can use additional processors to execute additional threads.(But watch out for multi-threaded software that assumes its running onauniprocessor, so when a high priority thread is running, a low prioritythread isn't.)
Asymmetric multiprocessors, which lack shared memory, havedissimilarprocessors or run different operating systems on different processorsare more difficult to program, but increasingly common. Threads ofexecution on different processors are isolated from each other andcannot directly access the same data. The software must ensure thatthreads have the data they need when they need it. Results may beaffected by the order in which events occur on different processors.
Asymmetric multiprocessors are effectively distributed systems andsomeof the tools and techniques of distributed systems can help us addressthese problems.
One example is a computational model involving threadscommunicating by exchanging messages using inter-process communications(IPC). This model is attractive because it reflects the underlyingreality, but it has limitations. It introduces a new basis of softwarepartitioning – the message – in addition to the familiar concepts offunction calls and member function calls. It forces the developer todeal with remote processing and local processing in different terms andto make up front decisions about what can and cannot be accomplishedremotely. It also forces early decisions on where different processingis done.
Consider what happens if we start a high level design bypartitioning anapplication into threads exchanging messages. When a message is passedto a thread on the local processor, a message passing overhead (albeitreduced) is incurred, so message passing must be used sparingly andonlywhere remote processing 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 architect