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