Design and Implementation of TinyGALS: A Programming Model for ...
Design and Implementation of TinyGALS: A Programming Model for ...
Design and Implementation of TinyGALS: A Programming Model for ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
integrate subsystems that share a common tick (an abstract notion <strong>of</strong> an instant in time)<br />
[8]. Our notions <strong>of</strong> synchronous <strong>and</strong> asynchronous are consistent with the usage <strong>of</strong> these<br />
terms in distributed programming paradigms [31]. We use synchronous to mean that the<br />
s<strong>of</strong>tware flow <strong>of</strong> control transfers immediately to another component <strong>and</strong> the calling code<br />
blocks awaiting return. Steps do not take infinite time; control eventually returns to the call-<br />
ing code. Asynchronous means that control flow does not transfer immediately to another<br />
component; execution <strong>of</strong> the other component is decoupled.<br />
Our programming model, called <strong>TinyGALS</strong>, uses two levels <strong>of</strong> hierarchy to build an ap-<br />
plication on a single processor. At the application level, modules communicate with each<br />
other asynchronously via message passing. Within each module, components communicate<br />
synchronously via method calls, as in most imperative languages. Thus, the programming<br />
model is globally asynchronous <strong>and</strong> locally synchronous in terms <strong>of</strong> the method call mech-<br />
anisms. If modules exchange data that is frequently updated, then message passing at<br />
the global level may become inefficient. In our model, a set <strong>of</strong> guarded yet synchronous<br />
variables (called TinyGUYS) is provided at the system level <strong>for</strong> asynchronous modules to<br />
exchange global in<strong>for</strong>mation “lazily”. These variables are thread-safe, yet components can<br />
quickly read their values. In this programming model, application developers have precise<br />
control over the concurrency in the system, <strong>and</strong> they can develop s<strong>of</strong>tware components<br />
without the burden <strong>of</strong> thinking about multiple threads.<br />
In a reactive, event-driven system, most <strong>of</strong> the processor time is spent waiting <strong>for</strong> an ex-<br />
ternal trigger or event. A reasonably small amount <strong>of</strong> additional code to enhance s<strong>of</strong>tware<br />
modularity will not greatly affect the per<strong>for</strong>mance <strong>of</strong> the system. Automatically gener-<br />
ated code reduces implementation <strong>and</strong> debug time, since the developer does not need to<br />
reimplement st<strong>and</strong>ard constructs (e.g. communication ports, queues, functions, guards on<br />
variables), <strong>and</strong> the generated code will not contain errors.<br />
In this report, we describe a method <strong>for</strong> generating code <strong>for</strong> applications that use the<br />
<strong>TinyGALS</strong> programming model. In this s<strong>of</strong>tware synthesis technique, code <strong>for</strong> commu-<br />
nication <strong>and</strong> scheduling is automatically generated from applications specified using the<br />
4