Networking and multicore chips inevitably create greater complexity, which requires solutions replete with sophisticated communication and thread management. Distributing the load is the desired result, allowing more hardware to be incorporated into a system in a coordinated fashion. The development task isn’t easy, but the use of one or more software frameworks can alleviate some of the stresses.
“Software frameworks,” a wonderfully vague term, covers a lot of ground. It’s been applied to language-based platforms like Java and Microsoft’s .NET as well as graphical interfaces, Web server platforms, and a host of other software areas.
While distributed communications and process coordination includes Intel’s Thread Building Blocks (see “Threads Make The Move To Open Source” at www.electronicdesign.com, ED Online 16538), it also includes Data Distribution Service (DDS) for Real-time Systems, the Message Passing Interface (MPI), and the Concurrency and Coordination Runtime (CCR) that’s part of the Microsoft Robotics Studio (see “MS Robotics Studio” at ED Online 16631).
In theory, all three could be used within a system since they address different issues, though developers typically try to minimize the number of frameworks within a design simply to reduce complexity. Still, the use of frameworks can significantly cut down the amount of new code required for a job. It also can address features that otherwise might not be considered, such as multilevel security and redundancy.
Likewise, these data-centric frameworks often provide scalability that’s not available with other approaches. In fact, all three are designed to scale to very large environments with thousands of nodes. While these frameworks are commonly deployed in large networks, they’re also of interest in more compact solutions with ever-increasing amounts of cores on a chip or board.
DISTRIBUTING DATA
The DDS for Real-time Systems Specification comes from the Object Management Group (OMG), which brought such favorites as UML (Universal Modeling Language) and the Common Object Request Broker Architecture (CORBA). CORBA is another data-distribution system, but it employs direct connections and remote procedure calls (RPCs), whereas DDS uses a publish/subscribe architecture (Fig. 1). Companies such as Real-Time Innovations and PrismTech provide DDS implementations. Other publish-subscribe models include the Java Message Service (JMS).
Unlike direct connect systems like CORBA and Sockets, DDS information may go nowhere. The concept of lifespan means the validity of information may expire before delivery. The DDS system handles delivery, which is based on the type, called topic, of data that’s generated. The ability to specify different information and quality of service (QoS) by subscribers and publishers allows designers to create large and robust systems. The system uses a platform-independent model that makes DDS easier to deploy in heterogeneous environments.
At the heart of DDS lies the Data Centric Publish-Subscribe (DCPS) layer. This interface enables applications to describe and publish data that’s automatically distributed to subscribers, which specify the type of data they’re looking for. Policies can be used to control parameters such as resource limits and QoS. Subscribers can also track liveliness that indicates whether the publisher is still alive if it hasn’t generated any data in some time.
Data can be filtered by content or by time, which is a critical divergence from the normal explicit multithreading constructs. It provides a significant performance optimization, since tests can be performed at the source with only the requested data being sent to a subscriber. Deadlines, latency, and other timing aspects are well defined with DDS, not implicit within application code.
Like most communication systems, DDS defines support for dataflow routing, discovery, and data typing. DDS also provides data filtering, transformation, and connectivity monitoring services plus the ability to specify redundancy and replication, and delivery effort. It can also handle resource management and status notifications.
The Data Local Reconstruction Layer (DLRL) is an optional portion of the DDS specification. It provides seamless integration with the native languages like C and C++. Typical DDS runtimes are decentralized in their implementation. This allows for a more robust solution and one that’s at home with transient connections. Overall, DDS takes a relatively simple publish-subscribe model and wraps it in a rather extensive test of functions that can service a wide range of applications.
MANY MESSAGES
MPI is typically used in high-performance computing (HPC), though the architecture applies to a range of applications with a large number of processors. It provides a number of communication mechanisms that work on a range of platforms, from shared-memory systems to networked computers (Fig. 2). Designed for use in applications where processes cooperate with each other, it can handle groups or collections of processes as well as hierarchical process groups.
MPI implementations support the standard MPI application programming interface (API) in addition to the runtime support necessary for both message passing and distributed thread control. The system supports blocking and non-blocking messaging. It also provides fine-grain control of remote threads and processes. MPI generally is built atop sockets-based standard protocols such as TCP/IP.
Processes are grouped into objects called communicators. Communication can occur within the communicator as well as between communicators. Each process within a communicator has a rank. A communicator can have one or more contexts that partition the communication space. It also controls the scope of communication.
MPI addresses a range of communication methodologies, from basic pointto- point messaging to parallel operations such as scatter-gather distribution as well as broadcasting and summation-style operations. These operations include sum, max, and min in addition to user-defined functions.
Continue to page 2
Reprints
