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

More documents

Recommendations

Info

critical section to maintain data integrity. However, instead of using semaphores, Echidna constraints when preemption can occur. To summarize, in both the PBO and FPBO model, the software components only communicate with other components via SVARs, which are similar to global variables. Updates to an SVAR are made atomically, and the components always read the latest value of the SVAR. The SVAR concept is the motivation behind the TinyGUYS strategy of always read- ing the latest value. However, in TinyGALS, since components within a module may be tightly coupled in terms of data dependency, updates to TinyGUYS are buffered until a module has completed execution. This is more closely related to the local tables in the Chimera implementation than the global tables in the Echidna implementation. However, there is no possibility of blocking when using the TinyGUYS mechanism. 6.3 Click Click [25, 24] is a flexible, modular software architecture for creating routers. A Click router configuration consists of a directed graph, where the vertices are called elements and the edges are called connections. In this section, we provide a detailed description of the constructs and processing in Click and compare it to TinyGALS. Elements in Click An element is a software module which usually performs a simple computation as a step in packet processing. An element is implemented as a C++ object that may maintain private state. Each element belongs to one element class, which spec- ifies the code that should be executed when the element processes a packet, as well as the element’s initialization procedure and data layout. An element can have any number of input and output ports. There are three types of ports: push, pull, and agnostic. In Click diagrams, push ports are drawn in black, pull ports in white, and agnostic ports with a double outline. Each element supports one or more method interfaces, through which they communicate at runtime. Every element supports the simple packet-transfer interface, 46
ut elements can create and export arbitrary additional interfaces. An element may also have an optional configuration string which contains additional arguments that are passed to the element at router initialization time. The Click configuration language allows users to define compound elements, which are router configuration fragments that behave like element classes. At initialization time, each use of a compound element is compiled into the corresponding collection of simple elements. Figure 21 shows an example Click element that belongs to the Tee element class, which sends a copy of each incoming packet to each output port. The element has one input port. It is initialized with the configuration string “2”, which in this case configures the element to have two output ports. element class input port Tee(2) output ports configuration string Figure 21: An example Click element. Connections in Click A connection represents a possible path for packet handoff and attaches the output port of an element to the input port of another element. A connection is implemented as a single virtual function call. A connection between two push ports is a push connection, where packet handoff along the connection is initiated by the source element (or source end, in the case of a chain of push connections). A connection between two pull ports is a pull connection, where packet handoff along the connection is initiated by the destination element (or destination end, in the case of a chain of pull connections). An agnostic port behaves as a push port when connected to push ports and as a pull port when connected to pull ports, but each agnostic port must be used as push or pull exclusively. In addition, if packets arriving on an agnostic input might be emitted immediately on an agnostic output, then both input and output must be used in the same way (either push or pull). When a Click router is initialized, the system propagates constraints until every agnostic port has been assigned to either push or pull. A connection between a push port 47
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 12 and 13: integrate subsystems that share a c
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 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 ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?