Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

Distributed framework for multicores

Posted: 17 Jul 2006 ?? ?Print Version ?Bookmark and Share

Keywords:Dominic Herity? Redplain? model framework? multicore? multiprocessor?

Herity: A distributed object model brings all the benefits of object-oriented programming to multicore processing.

Multiprocessors are becoming a fact of life for most software and embedded systems engineers. Symmetric multiprocessors use many identical processors, an OS and a shared memory. They are relatively easy to program, since additional processors can be used to execute additional threads.

Asymmetric multiprocessors, on the other hand, lack shared memory and have dissimilar processors or run different operating systems on different processors. They are more difficult to program, but are increasingly common. Threads of execution on different processors are isolated from one another and cannot directly access the same data. The software must ensure that threads have the data they need when they need it. Results may be affected by the order in which events occur on different processors.

Asymmetric multiprocessors are effective distributed systems, and some of the tools and techniques of distributed systems can help address certain problems.

One is a computational model involving threads communicating by exchanging messages using interprocess communications. It introduces a new basis of software partitioningthe messagein addition to the familiar concepts of function calls and member function calls. It forces the developer to deal with remote and local processing in different terms, and to make upfront decisions about what can and cannot be accomplished remotely. It also forces early decisions on where different processing is done. This approach commits us to the location of data and of processing before we have a good understanding of our new design's behavior. If we get it wrong, or if the hardware environment changes, we have to start over.

A distributed object model is an alternative to the threads and messages approach. It brings all the benefits of object-oriented programming and adds some benefits of its own. It divides application data into discrete objects, allowing us to assign processing to different processors by locating objects on them.

Consider what happens if we model an application in terms of distributed objects instead of threads and messages. A detailed system model can be built in terms of objects and methods without undue attention to object location. I say undue attention because object location must be borne in mind in key scenarios, but need not be completely specified at the outset.

We don't worry too much about whether a method call is local or remote. The message passing layer is a consequence of the classes and methods that are remotely accessed, which are consequences of object location.

Object location can be decided late and changed easily. When it is decided or changed, the message passing layer can be automatically generated, not handwritten. So, distributed object design methodology can reduce the cost and increase the flexibility of a distributed application. Load balancing and ports to different hardware architectures can be addressed by reassigning objects to different processors.

Distributed object middleware has been very successful in traditional distributed processing. CORBA, COM and Java remote method invocation are well-known implementations of the paradigm. But these technologies are designed for big computers with big operating systems on slow networks. They focus largely on defining and implementing interfaces between subsystems, with each subsystem confined to an individual processor. Used carelessly, they yield disappointing results.

The multicore environment demands distributed object middleware as small and fast as hand-optimized message passing. It must be highly transparent to allow most objects to be remotely accessed. Remote invocation must be like walking into another room, not visiting another house. If this can be achieved, distributed object technology can significantly reduce the difficulty, risk and cost of software development for asymmetric multiprocessors.

- Dominic Herity
Chief Technology Officer, Redplain Technology

Article Comments - Distributed framework for multicores
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top