Difference between revisions of "Frequently Asked Questions (FAQs)"

From TinyOS Wiki
Jump to: navigation, search
(What is the purpose of the ''signal'' and ''call'' keywords? Aren't they really both just annotating regular function calls?)
m
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
== What is the purpose of the ''signal'' and ''call'' keywords?  Aren't they really both just annotating regular function calls? ==
+
== What is the purpose of the ''signal'' and ''call'' keywords?  Aren't they just unnecessarily annotating regular function calls? ==
  
 
You can think of an interface in TinyOS as containing two types of
 
You can think of an interface in TinyOS as containing two types of
Line 20: Line 20:
 
components are called using the 'call' keyword  For components
 
components are called using the 'call' keyword  For components
 
providing an interface, events implemented by another component are
 
providing an interface, events implemented by another component are
signaled vie the "signal" keyword.  In most common situations,
+
signaled via the "signal" keyword.  In most common situations,
 
commands and events within a single interface complement one another
 
commands and events within a single interface complement one another
 
in a split-phase manner.  That is to say, one component will perform
 
in a split-phase manner.  That is to say, one component will perform

Latest revision as of 02:35, 24 November 2008

What is the purpose of the signal and call keywords? Aren't they just unnecessarily annotating regular function calls?

You can think of an interface in TinyOS as containing two types of function calls: commands and events. Whenever a component 'provides' an interface it must implement all of the commands defined within it. Whenever a component 'uses' an interface, it must implement any events that it defines.

Components 'providing' an interface can rely on the fact that any events defined by that interface will be implemented by some other component and wired together with it via a configuration. Similarly, components 'using' an interface can also rely on the fact that any commands defined by that interface will be implemented by some other component. In this way, two components can exist in isolation, complementing one another via the contract defined through the common interface that they share. The distinction comes from whether they 'provide' or 'use' that interface.

For components using an interface, commands provided by other components are called using the 'call' keyword For components providing an interface, events implemented by another component are signaled via the "signal" keyword. In most common situations, commands and events within a single interface complement one another in a split-phase manner. That is to say, one component will perform some operation by calling a command and will then wait for an event to be signaled before continuing execution. The command will be provided by some other component, who is in charge of signaling the event once the operation is complete. Since the original component 'uses' the shared interface, it will be in charge of implementing the body of the signaled event however it chooses. In this way, one can think of "calling" commands from the top down, and "signaling" events from the bottom up. In the end though, they are both really just function calls to other components. The ' call' and 'signal' keywords are there to make it clear in which direction they are moving.

Historically though, the distinction between the two was actually necessary. Originally, TinyOS was made up of a bunch of Perl scripts that munged some cpp macros. Two of these macros were:

TOS_CALL_COMMAND()
and
TOS_SIGNAL_EVENT()

They needed to be distinct because

TOS_COMMAND()
and
TOS_EVENT()

led to different names.