[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep106.txt, 1.2, 1.3

[Phil Levis]

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

Modified Files:
	tep106.txt 
Log Message:
Makefile for teps. Stylesheet is clearly the wrong way to do it in the long
term (disconnected clients will get a bad format), but I haven't
thought through the best way to do it yet.


Index: tep106.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep106.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** tep106.txt	15 Dec 2004 19:40:45 -0000	1.2
--- tep106.txt	15 Dec 2004 22:49:33 -0000	1.3
***************
*** 41,71 ****
  
  
! 2. Tasks in TinyOS 1.x
  ====================================================================
  
! Tasks in TinyOS are a form of deferred procedure call (DPC), 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[1].  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 mechanisms, *task* declarations and *post*
! expressions:
  
!   task void computeTask() {
!     // Code here
!   }
  
  and
  
!   result_t rval = post computeTask();
! 
  
-     
  
  TinyOS 1.x provides a single kind of task, a parameter-free function,
! and a single scheduling policy, FIFO.
  
  
--- 41,145 ----
  
  
! 2. Tasks and the Scheduler in TinyOS 1.x
  ====================================================================
  
! 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
! mechanisms, ``task`` declarations and ``post`` expressions:
  
! |  ``task void computeTask() {``
! |    ``// Code here``
! |  ``}``
  
  and
  
! |  ``result_t rval = post computeTask();``
  
  
  TinyOS 1.x provides a single kind of task, a parameter-free function,
! and a single scheduling policy, FIFO. ``post`` expressions can return
! FAIL, to denote that TinyOS was unable to post the task.  Tasks can be
! 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.
! 
! The TinyOS 1.x scheduler is implemented as a set of C functions in the
! file ``sched.c``. Modifying the scheduler requires replacing or
! changing this file. Additionally, as tasks are supported solely through
! nesC ``task`` declarations and ``post`` expressions, which assume
! a parameter-free function, modifying the syntax or capabilities of
! tasks is not possible.
! 
! The task queue in TinyOS 1.x is implemented as a fixed size circular
! buffer of function pointers. Posting a task puts the task's function
! pointer in the next free element of the buffer; if there are no free
! elements, the ``post`` returns fail. This model has several issues:
! 
!   1) Some components do not have a reasonable response to a failed ``post``
!   2) As a given task can be posted multiple times, it can consume more than one element in the buffer
!   3) All tasks from all components share a single resource: one misbehaving component cause other's posts to fail
! 
! 
! The combination of the above three issues mean that one misbehaving
! component can cause TinyOS to hang. Consider, for example, this
! scenario (a real and encountered problem on the Telos platform):
! 
!   * A packet-based hardware radio, which issues an interrupt only when it finishes sending a packet
!   * A networking component that handles the interrupt to post a task to signal ``SendMsg.sendDone``.
!   * A sensing component that posts a task when it handles an ``ADC.dataReady`` event
!   * An application component that sends a packet and then sets its ADC sampling rate too high
! 
! In this scenario, the sensing component will start handling events at
! a faster rate than it can process them. It will start posting tasks to
! handle the data it receives, until it fills the task queue. At some
! point later, the radio finishes sending a packet and signals its
! interrupt. The networking component, however, is unable to post its
! task that signals ``SendMsg.sendDone()``, losing the event. The
! application component does not try to send another packet until it
! knows the one it is sending completes (so it can re-use the
! buffer). As the ``sendDone()`` event was lost, this will never occur,
! 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.
! 
! 3. Tasks in TinyOS 2.x
! ====================================================================
! 
! TinyOS 2.x takes the position that the basic use case of tasks should
! remain simple and easy to use, but that it should be possible to
! introduce new kinds of tasks beyond the basic use case. TinyOS
! actualizes this by keeping ``post`` and ``task`` for the basic case,
! and introducing task interfaces for additional ones.
! 
! Task interfaces allow users to extend the syntax and semantics of
! tasks. Generally, a task interface has an ``async`` command, ``post``,
! and an event, ``run``. The exact signature of these functions are
! up to the interface. For example, a task interface that allows a task
! to take an integer parameter could look like this:
! 
! |  ``interface TaskParameter {``
! |    ``async result_t command post(uint16_t param);``
! |    ``event void run(uin16_t param);``
! |  ``}``
! 
! Using this task interface, a component could post a task with a
! ``uint16_t`` parameter. When the scheduler runs the task, it will
! signal the ``run`` event with the passed parameter, which contains
! the task's logic.
! 
! 
! 4. The Scheduler in TinyOS 2.x
! ====================================================================
!