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

Wed Jan 19 15:36:28 PST 2005

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

Modified Files:
	tep106.txt 
Log Message:
Changed runNextTask() to proper signature. Filled in 
"adding a new Scheduler."

Index: tep106.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep106.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep106.txt	18 Jan 2005 22:34:04 -0000	1.5
--- tep106.txt	19 Jan 2005 23:36:26 -0000	1.6
***************
*** 130,134 ****

  |  ``interface TaskParameter {``
! |    ``async result_t command post(uint16_t param);``
  |    ``event void run(uin16_t param);``
  |  ``}``
--- 130,134 ----

  |  ``interface TaskParameter {``
! |    ``async error_t command post(uint16_t param);``
  |    ``event void run(uin16_t param);``
  |  ``}``
***************
*** 139,144 ****
  the task's logic.

! .. Note::
!    Need to settle on exact basic task semantics.

  4. The Scheduler in TinyOS 2.x
--- 139,155 ----
  the task's logic.

! 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.
! 
! These semantics prevent several problems, such as the inability to
! signal completion of split-phase events because the task queue is
! full, task queue overflow at initialization, and unfair task
! allocation by components that post a task many times.
! 

  4. The Scheduler in TinyOS 2.x
***************
*** 146,159 ****

  In TinyOS 2.x, the scheduler is a TinyOS component. Every scheduler
! must support basic nesC tasks. It may also support any number of
  additional task interfaces. The scheduler component is resonsible for
  the policy of reconciling different task types (e.g., earliest
  deadline first tasks vs. priority tasks).

! .. Note::
!    The format and implementation of basic tasks greatly depends on their semantics. Need to hash this out.

! .. Note:: 
!    Need a better story on this. Separate component? Main?

--- 157,276 ----

  In TinyOS 2.x, the scheduler is a TinyOS component. Every scheduler
! MUST support basic nesC tasks. It MAY also support any number of
  additional task interfaces. The scheduler component is resonsible for
  the policy of reconciling different task types (e.g., earliest
  deadline first tasks vs. priority tasks).

! The basic task in TinyOS 2.x is parameterless and FIFO. Tasks continue
! to follow the nesC semantics of task and post, which are linguistic
! shortcuts for declaring a TaskBasic interface and wiring it to the
! Scheduler component. A scheduler provides a task interface as a
! parameterized interface. Every task that wires to the interface uses
! the unique() function to obtain a unique identifier, which the
! scheduler uses to dispatch tasks.

! For example, the standard TinyOS Scheduler has this signature:
! 
! |  ``module SchedulerBasic {``
! |    ``provides interface Scheduler;``
! |    ``provides interface TaskBasic[uint8_t taskID];``
! |  ``}``
! 
! The Scheduler interface has commands for initialization and running
! tasks, and is used by TinyOS to execute tasks.
! 
! |  ``interface SchedulerRun {``
! |    ``command void init();``
! |    ``command void runNextTask();``
! |  ``}``
! 
! The init() command initializes the task queue and scheduler data
! structures. runNextTask() MUST run to completion whatever task the
! scheduler's policy decides is the next one. If there are no tasks
! to execute, runNextTask() MAY put the CPU to sleep.
! 
! The TaskBasic interface is this:
! 
! |  ``interface TaskBasic {``
! |    ``async command error_t post();``
! |    ``void event run();``
! |  ``}``
! 
! When a component declares a task with the ``task`` keyword in nesC, it
! is implicitly declaring that it uses an instance of the TaskBasic
! 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
! entries.When TinyOS tells the Scheduler to run a task, it pulls the
! next identifier off the queue and uses it dispatches on the
! parameterized TaskBasic interface.
! 
! 
! 5. Replacing the Scheduler
! ====================================================================
! 
! The TinyOS scheduler is presented as a component named TinyScheduler.
! The default TinyOS scheduler implementation is a module named
! SchedulerBasic; the default Scheduler component is a configuration
! that provides wire-through of SchedulerBasic.
! 
! To replace the scheduler for a particular application, a developer
! SHOULD put a configuration named Scheduler in the application
! directory: this will replace the default. The Scheduler component
! provides a wire-through of the desired scheduler implementation. All
! scheduler implementations SHOULD provide a parameterize TaskBasic
! interface, as SchedulerBasic does; this supports nesC post statements
! and task declarations. All scheduler implementations MUST provide
! the Scheduler interface.
! 
! For example, imagine a hypothetical scheduler that provides earliest
! deadline first tasks, which are provided through the TaskEDF
! interface:
! 
! |  ``interface TaskEDF {``
! |    ``async command error_t post(uint16_t deadline);``
! |    ``void event run();``
! |  ``}``
! 
! The scheduler implementation is named SchedulerEDF, and provides both
! TaskBasic and TaskEDF interfaces:
! 
! |  ``module SchedulerEDF {``
! |    ``provides interface Scheduler;``
! |    ``provides interface TaskBasic[uint8_t taskID];``
! |    ``provides interface TaskEDF[uint8_t taskID];``
! |  ``}``
! 
! An application that wants to use SchedulerEDF instead of
! SchedulerBasic includes a configuration named TinyScheduler, which
! exports all of SchedulerEDF's interfaces:
! 
! |  ``configuration TinyScheduler {``
! |    ``provides interface Scheduler;``
! |    ``provides interface TaskBasic[uint8_t taskID];``
! |    ``provides interface TaskEDF[uint8_t taskID];``
! |  ``}``
! |  ``implementation {``
! |    ``components SchedulerEDF;``
! |    ``Scheduler = SchedulerEDF;``
! |    ``TaskBasic = SchedulerEDF;``
! |    ``TaskEDF   = SchedulerEDF;``
! |  ``}``
! 
! For a module to have an earliest deadline first task, it uses the
! TaskEDF interface. Its configuration SHOULD wire it to TinyScheduler,
! using a unique value generated from the key "TaskEDF." For example:
! 
! |  ``configuration SomethingC {``
! |    ``...``
! |  ``}``
! |  ``implementation {``
! |    ``components SomethingM, TinyScheduler;``
! |    ``SomethingM.TaskEDF -> TinyScheduler.TaskEDF["TaskEDF"];``
! |    ``TaskBasic = SchedulerEDF;``
! |    ``TaskEDF   = SchedulerEDF;``
! |  ``}``