Design and Implementation of TinyGALS: A Programming Model for ...

does not require synchronization, which will result in a large footprint and slow execution. 1
Unlike software for traditional computer systems, software for embedded systems is
application-specific and often encapsulates domain expertise, especially when it must pro-
cess sensor data or control actuators [27]. As a result, although concurrency has long been
a key research theme for systems software such as operating systems and distributed com-
puting middleware [6, 33, 32], formal treatment of them in embedded systems has largely
been ignored by mainstream computer science researchers until recently. The application-
specific nature of embedded software, combined with tight constraints on available pro-
cessing power and memory space, make traditional approaches such as the use of layers of
abstraction and middleware less applicable. A more promising approach is to use formal
concurrency models to construct and analyze software designs, and to use software synthe-
sis technologies to generate application-specific scheduling and execution frameworks that
give designers fine-grained control of timing, concurrency, and memory usage.
One example of this more formal approach are the synchronous languages for reactive
systems [9]. Languages such as Esterel [10] allow users to specify a system using the
notion of global ticks and concurrent zero delay reactions. Their models are specific enough
that the concurrency in the system can be compiled away, and the system behaves like a
state machine at run time. Actor-oriented designs, such as those seen in the Ptolemy II
framework [11], integrate a rich set of sequential and concurrent models, use a system-level
type system to check their composability [28], and compile away as much concurrency as
possible to obtain run-time efficiency and predictability [12]. These approaches give us a
way to formally coordinate the concurrency inherent in the system.
1 Herlihy proposes a methodology in [19] for constructing non-blocking and wait-free implementations of
concurrent objects. Programmers implement data objects as stylized sequential programs, with no explicit
synchronization. Each sequential operation is automatically transformed into a non-blocking or wait-free op-
eration via a collection of synchronization and memory management techniques. However, operations may
not have any side-effects other than modifying the memory block occupied by the object. This does not ad-
dress the need for inter-object communication when composing components. Additionally, this methodology
requires additional memory copying, which may become expensive for large objects.
2