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

More documents

Recommendations

Info

integrate subsystems that share a common tick (an abstract notion of an instant in time) [8]. Our notions of synchronous and asynchronous are consistent with the usage of these terms in distributed programming paradigms [31]. We use synchronous to mean that the software flow of control transfers immediately to another component and the calling code blocks awaiting return. Steps do not take infinite time; control eventually returns to the calling code. Asynchronous means that control flow does not transfer immediately to another component; execution of the other component is decoupled. Our programming model, called TinyGALS, uses two levels of hierarchy to build an application on a single processor. At the application level, modules communicate with each other asynchronously via message passing. Within each module, components communicate synchronously via method calls, as in most imperative languages. Thus, the programming model is globally asynchronous and locally synchronous in terms of the method call mech- anisms. If modules exchange data that is frequently updated, then message passing at the global level may become inefficient. In our model, a set of guarded yet synchronous variables (called TinyGUYS) is provided at the system level for asynchronous modules to exchange global information “lazily”. These variables are thread-safe, yet components can quickly read their values. In this programming model, application developers have precise control over the concurrency in the system, and they can develop software components without the burden of thinking about multiple threads. In a reactive, event-driven system, most of the processor time is spent waiting for an ex- ternal trigger or event. A reasonably small amount of additional code to enhance software modularity will not greatly affect the performance of the system. Automatically generated code reduces implementation and debug time, since the developer does not need to reimplement standard constructs (e.g. communication ports, queues, functions, guards on variables), and the generated code will not contain errors. In this report, we describe a method for generating code for applications that use the TinyGALS programming model. In this software synthesis technique, code for communication and scheduling is automatically generated from applications specified using the 4
TinyGALS language constructs, as well as code for guarding access to TinyGUYS global variables. We have implemented this for use on the MICA motes [15], a wireless sensor network platform. The TinyGALS programming model and code generation facilities can greatly improve software productivity and encourage component reuse. Our model is influenced by the TinyOS project at the University of California, Berke- ley [21]. We use the TinyOS component specification syntax in our tools so that users can reuse existing TinyOS v0.6.1 [5] components in TinyGALS applications. TinyOS components provide an interface abstraction that is consistent with synchronous communication via method calls. However, unlike our model, concurrent tasks in TinyOS are not ex- posed as part of the component interface. Lack of explicit management of concurrency forces component developers to manage concurrency by themselves (locking and unlock- ing semaphores), which makes TinyOS components extremely difficult to develop. Our approach differs from coordination models like those discussed above in that we allow designers to directly control the concurrent execution and buffer sizes among asynchronous modules. At the same time, we use a thread-safe global data space to store mes- sages that do not trigger reactions. Components in our model are entirely sequential, and they are both easy to develop and backwards compatible with most legacy software. We also do not rely on the existence of an operating system. Instead, we generate the scheduling framework as part of the application. The remainder of this report is organized as follows. Section 2 describes the TinyGALS language constructs and semantics. Section 3 discusses issues related to determinacy of a TinyGALS program. Section 4 explains a code generation technique based on the two- level execution hierarchy and a system-level scheduler. Section 5 gives an example of developing a multi-hop routing protocol using the TinyGALS model. Section 6 discusses related work, emphasizing relevant embedded software models. Section 7 concludes this report and describes directions for future work. 5
Page 1: Design and Implementation of TinyGA
Page 5 and 6: Contents 1 Introduction 1 2 The Tin
Page 7: 8 Acknowledgements 60 iii
Page 10 and 11: does not require synchronization, w
Page 14 and 15: 2 The TinyGALS Programming Model Ti
Page 16 and 17: 2.2.1 TinyGALS Components Component
Page 18 and 19: Component implementation for COUNTE
Page 20 and 21: Module definition for leds. include
Page 22 and 23: uns in a single thread of execution
Page 24 and 25: as in a normal method call. 8 The g
Page 26 and 27: nondeterministic component firing o
Page 28 and 29: module. Tokens are placed in input
Page 30 and 31: Application def. include modules{ A
Page 32 and 33: 1. The values of all internal varia
Page 34 and 35: Conditions for well-formedness Here
Page 36 and 37: Determinacy of a system without glo
Page 38 and 39: I0 q0 I1 I2 In a 1 0,0 a 1 0,0 + a2
Page 40 and 41: app_init() app_start() statevar_PAR
Page 42 and 43: the same name as the output port. T
Page 44 and 45: if there is an event in the global
Page 46 and 47: 5 Example The TinyGALS programming
Page 48 and 49: the motes as three separate modules
Page 50 and 51: Table 4: Code size comparison of BL
Page 52 and 53: gered modules in TinyGALS and tasks
Page 54 and 55: critical section to maintain data i
Page 56 and 57: and a pull port is illegal. Every p
Page 58 and 59: Poll packet from receive DMA ring P
Page 60 and 61: Click router thread TinyGALS thread
Page 62 and 63:
unlike Click, the TinyGALS model do
Page 64 and 65:
6.5 Timed Multitasking Timed multit
Page 66 and 67:
quiescent system state to the next
Page 68 and 69:
8 Acknowledgements I wish to thank
Page 70 and 71:
[11] S. S. Bhattacharyya, E. Cheong
Page 72 and 73:
[31] T. J. Mowbray, W. A. Ruh, and
show all

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

Create successful ePaper yourself

Delete template?

Save as template?