Addressed review comments.

diff --git a/doc/txt/tep106.txt b/doc/txt/tep106.txt
index 4c9d1e5deb61d3e50df58ec4319aebb6b7ae79da..971e44ee090548af06d5a541953e868342cf1b73 100644 (file)
--- a/doc/txt/tep106.txt
+++ b/doc/txt/tep106.txt
@@ -178,9 +178,8 @@ to take an integer parameter could look like this::
 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 ``runTask`` event with the passed parameter, which contains
-the task's logic. Note, however, that this does not save any RAM: if
-anything, it will cost RAM as space must be allocated in the scheduler
-and may then also be allocated in the component. Furthermore, as
+the task's logic. Note, however, that this does not save any RAM: 
+the scheduler must have RAM allocated for the parameter.  Furthermore, as
 there can only be one copy of a task outstanding at any time, it
 is just as simple to store the variable in the component. E.g.,
 rather than::
@@ -271,6 +270,11 @@ runNextTask(TRUE) always return TRUE.   The taskLoop() command tells
 the scheduler to enter an infinite task-running loop, putting the MCU
 into a low power state when the processor is idle: it never returns.
 
+The scheduler is repsonsible for putting the processor to sleep
+predominantly for efficiency reasons. Including the sleep call
+within the scheduler improves the efficiency of the task loop,
+in terms of the assembly generated by the TinyOS toolchain. 
+
 This is the TaskBasic interface::
 
   interface TaskBasic {  
@@ -293,6 +297,10 @@ entries. When TinyOS tells the scheduler to run a task, it pulls the
 next identifier off the queue and uses it to dispatch on the
 parameterized TaskBasic interface.
 
+While the default TinyOS scheduler uses a FIFO policy, TinyOS
+components MUST NOT assume a FIFO policy. If two tasks must run
+in a particular temporal order, this order should be enforced by
+the earlier task posting the later task.
 
 5. Replacing the Scheduler
 ====================================================================
@@ -396,7 +404,9 @@ implementation of SomethingP that uses keywords for basic tasks::
 The requirement that basic tasks not be subject to starvation
 requires that a scheduler supporting EDF tasks must ensure that
 basic tasks run eventually even if there is an unending stream of
-short deadline tasks to run.
+short deadline tasks to run. Quantifying "eventually" is difficult,
+but a 1% share of the MCU cycles (or invocations) is a reasonable 
+approximation. 
 
 If the scheduler provides two instances of the same task interface,
 their unique keys are based on the name of the interface as the