[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep106.txt, 1.8, 1.9 tep107.txt, 1.3, 1.4

Sun Jun 26 11:54:32 PDT 2005

Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2071

Modified Files:
	tep106.txt tep107.txt 
Log Message:
Updated.

Index: tep106.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep106.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** tep106.txt	14 Feb 2005 20:28:18 -0000	1.8
--- tep106.txt	26 Jun 2005 18:54:27 -0000	1.9
***************
*** 25,29 ****
  ====================================================================

! This memo documents the structure and implementation of TinyOS tasks
  and task schedulers in TinyOS 2.x.

--- 25,29 ----
  ====================================================================

! This memo documents the structure and implementation of tasks
  and task schedulers in TinyOS 2.x.

***************
*** 45,54 ****
  ====================================================================

! Tasks in TinyOS are a form of deferred procedure call (DPC)[1], which
  enable a program to defer a computation or operation until a later
  time. TinyOS tasks run to completion and do not pre-empt one
! another[2].  These two constraints mean that code called from tasks
  runs synchonously with respect to other tasks. Put another way, tasks
! are atomic with respect to other tasks[3].

  In TinyOS 1.x, the nesC language supports tasks through two
--- 45,54 ----
  ====================================================================

! Tasks in TinyOS are a form of deferred procedure call (DPC)[1]_, which
  enable a program to defer a computation or operation until a later
  time. TinyOS tasks run to completion and do not pre-empt one
! another.  These two constraints mean that code called from tasks
  runs synchonously with respect to other tasks. Put another way, tasks
! are atomic with respect to other tasks[2]_.

  In TinyOS 1.x, the nesC language supports tasks through two
***************
*** 69,73 ****
  posted multiple times. For example, if a task is posted twice in quick
  succession and the first succeeds while the second fails, then the
! task will be run in the future; for this reason, even if a ``post``
  fails, the task may run.

--- 69,73 ----
  posted multiple times. For example, if a task is posted twice in quick
  succession and the first succeeds while the second fails, then the
! task will be run once in the future; for this reason, even if a ``post``
  fails, the task may run.

***************
*** 109,117 ****
  and the application stops sending network traffic.

! The solution to this problem in TinyOS 1.x is to signal sendDone() in
! the radio send complete interrupt if the post fails: this violates the
! sync/async boundary, but the justification is that a *possible* rare
! race condition is better than *certain* failure. The TinyOS 1.x model
! prevents it from doing any better.

  3. Tasks in TinyOS 2.x
--- 109,117 ----
  and the application stops sending network traffic.

! The solution to this particular problem in TinyOS 1.x is to signal 
! sendDone() in the radio send complete interrupt if the post fails: 
! this violates the sync/async boundary, but the justification is that 
! a *possible* rare race condition is better than *certain* failure. 
! The TinyOS 1.x model prevents it from doing any better.

  3. Tasks in TinyOS 2.x
***************
*** 142,148 ****
  The semantics of tasks in TinyOS 2.x are different than those in 1.x.
  This change is based on experiences with the limitations and run time
! errors that the 1.x model introduces. In TinyOS 2.x, a basic post will
  only fail if the task has already been posted and has not started
! execution. A task can always run, but can only have one outstanding
  post at any time. If a component needs to post task several times,
  then the end of the task logic can repost itself as need be.
--- 142,148 ----
  The semantics of tasks in TinyOS 2.x are different than those in 1.x.
  This change is based on experiences with the limitations and run time
! errors that the 1.x model introduces. **In TinyOS 2.x, a basic post will
  only fail if the task has already been posted and has not started
! execution.** A task can always run, but can only have one outstanding
  post at any time. If a component needs to post task several times,
  then the end of the task logic can repost itself as need be.
***************
*** 178,181 ****
--- 178,188 ----
  |  ``}``

+ A scheduler MUST provide a parameterized TaskBasic interface.
+ If a call to TaskBasic.post() returns SUCCESS, the scheduler MUST run it
+ eventually. The scheduler MUST return SUCCESS to a TaskBasic.post()
+ operation unless it is not the first call to TaskBasic.post() since
+ that task's TaskBasic.run() event has been signaled.
+ 
+ A scheduler MUST provide the Scheduler interface. 
  The Scheduler interface has commands for initialization and running
  tasks, and is used by TinyOS to execute tasks.
***************
*** 192,199 ****
  scheduler should do if there are no tasks to execute. If sleep is
  FALSE, then the command will return immediately with FALSE as a return
! value. If sleep is TRUE, then the command will not return until a task
  is executed, and SHOULD put the CPU to sleep until a new task arrives.
  Calls of runNextTask(FALSE) may return TRUE or FALSE; calls of
! runNextTask(TRUE) always return TRUE.

  The TaskBasic interface is this:
--- 199,206 ----
  scheduler should do if there are no tasks to execute. If sleep is
  FALSE, then the command will return immediately with FALSE as a return
! value. If sleep is TRUE, then the command MUST NOT return until a task
  is executed, and SHOULD put the CPU to sleep until a new task arrives.
  Calls of runNextTask(FALSE) may return TRUE or FALSE; calls of
! runNextTask(TRUE) always return TRUE. 

  The TaskBasic interface is this:
***************
*** 208,212 ****
  interface: the task body is the run event. When a component uses the
  ``post`` keyword, it calls the post command. Each TaskBasic MUST be
! wired to the Scheduler with a unique identifier.

  The SchedulerBasic implementation uses these identifiers as its queue
--- 215,221 ----
  interface: the task body is the run event. When a component uses the
  ``post`` keyword, it calls the post command. Each TaskBasic MUST be
! wired to the Scheduler with a unique identifier as its parameter. 
! The parameter MUST be obtained with the ``unique`` function in nesC, 
! with a key of ``"BasicScheduler.TaskBasic"``.

  The SchedulerBasic implementation uses these identifiers as its queue
***************
*** 298,301 ****
  ====================================================================

! .. [rst] reStructuredText Markup Specification. <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html>

--- 307,317 ----
  ====================================================================

! .. [1] Deferred Procedure Calls. Some paper somewhere.
! 
! .. [2] David Gay, Philip Levis, Rob von Behren, Matt Welsh, Eric Brewer
! and David Culler. "The *nesC* Language: A Holistic Approach to Networked
! Embedded Systems." In *Proceedings of the ACM SIGPLAN 2003 Conference on
! Programming Language Design and Implementation (PLDI).* 
! 
! 

Index: tep107.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep107.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep107.txt	20 Jun 2005 22:59:14 -0000	1.3
--- tep107.txt	26 Jun 2005 18:54:27 -0000	1.4
***************
*** 111,125 ****
  The TinyOS 2.x boot sequence uses three interfaces:

!   o Initialize, for initializing component/hardware state
    o Scheduler, for initializing and running tasks
    o Boot, for signalling that the system has successfully booted

! The Initialize interface has a single command, init():

! |  ``interface Initialization {``
  |    ``command error_t init();``
  |  ``}``

! It provides a synchronous interface, enabling initialization
  ordering. Unlike normal execution, in which operations from a wide
  range of components need to be interleaved effectively, initialization
--- 111,125 ----
  The TinyOS 2.x boot sequence uses three interfaces:

!   o Init, for initializing component/hardware state
    o Scheduler, for initializing and running tasks
    o Boot, for signalling that the system has successfully booted

! The Init interface has a single command, init():

! |  ``interface Init {``
  |    ``command error_t init();``
  |  ``}``

! Init provides a synchronous interface, enabling initialization
  ordering. Unlike normal execution, in which operations from a wide
  range of components need to be interleaved effectively, initialization
***************
*** 127,132 ****
  until initialization is complete. If a particular component's
  initialization requires waiting for interrupts or other asynchronous
! events, then it must explicitly wait for them (e.g., by sleeping or
! with a spin loop), and not return until complete. Otherwise the system
  may start before initialization is complete.

--- 127,132 ----
  until initialization is complete. If a particular component's
  initialization requires waiting for interrupts or other asynchronous
! events, then it must explicitly wait for them (e.g., 
! with a spin loop), MUST NOT return until complete. Otherwise the system
  may start before initialization is complete.

***************
*** 155,160 ****
  |    ``uses {``
  |      ``interface Scheduler;``
! |      ``interface Initialize as PlatformInit;``
! |      ``interface Initialize as SoftwareInit;``
  |    ``}``
  |  ``}``
--- 155,160 ----
  |    ``uses {``
  |      ``interface Scheduler;``
! |      ``interface Init as PlatformInit;``
! |      ``interface Init as SoftwareInit;``
  |    ``}``
  |  ``}``
***************
*** 162,166 ****
  |    ``int main() __attribute__ ((C, spontaneous)) {``
  |      ``call Scheduler.init();``
- |      ``__nesc_enable_interrupts();``
  |      `` ``
  |      ``call PlatformInit.init();``
--- 162,165 ----
***************
*** 170,173 ****
--- 169,174 ----
  |      ``while(call Scheduler.runNextTask(FALSE));``
  |      `` ``
+ |      ``__nesc_enable_interrupts();``
+ |      `` ``
  |      ``signal Boot.booted();``
  |      ``while(1) {``
***************
*** 177,181 ****
--- 178,199 ----
  |  ``}``

+ Interrupts are not enabled until all calls to Init.init have returned.
+ If a component's initialization needs to handle interrupts, it can
+ do one of two things:
+ 
+   1) If a status flag for the interrupt exists, the Init.init()
+      implementations SHOULD use a spin loop to test for when
+      an interrupt has been issued.
+   2) If no such flag exists, the Init.init() implementation may
+      temporarily enable interrupts. It MUST NOT call any other
+      component or return unless it has re-disabled interrupts.

+ The Init.init() command MUST NOT call any commands or signal any
+ events, except for calling Init.init() on other components. A
+ component SHOULD NOT call Init.init() on other components unless
+ it needs to enforce a temporal ordering on initialization. If a
+ component A depends on another component, B, which needs to be 
+ initialized, then A SHOULD wire B's Init directly to the boot
+ sequence, unless there is a temporal ordering requirement.

  5. Author's Address