[Tinyos Core WG] [Tinyos-devel] TOSThreads TEP

[Philip Levis]

On May 21, 2008, at 8:47 AM, Neil Hancock wrote:

> Hi All
> Is this TEP available – sounds an interesting discussion.
>
> Personally, with 20years of real-time headaches I really support the  
> TinyOS split phase event driven model – a washing-machine controller  
> with limited RAM isn’t for everyone -- oops sorry I meant  a low  
> cost mote with a high degree of hardware integration and limited  
> resources isn’t for everyone – so the “spawnAnewThread” programming  
> model doesn’t seem likely to ever be viable on low cost TinyOS.
> It would be nice though to be able to have a low priority background  
> task that can run when nothing else is running.  On a number of  
> large systems I’ve worked on, with the capability of having 250+  
> task  priorities, we’ve limited the system to a band of 4 or 5 task  
> priorities– and then run tasks within that band on a round robbin  
> basis. Its just too hard to predict system behavior with too many  
> task priorities.

I think that's exactly right. Just as in a traditional OS, if you want  
something to be high performance, or be able to really control its  
execution, you put it inside the kernel and deal with the concurrency  
model inside (bottom halves, etc.). But if you just want a simple app,  
e.g., an echo, then there's no reason to not put it in a thread.

Furthermore, some things are really just *so* hard without threads.  
Essentially, any CPU-intensive operation. There are language  
approaches for taking threaded code and automatically breaking it up  
into chunks with explicit yield points, but if we can avoid requiring  
additional language layers, I think that's beneficial. It's not to say  
that TinyOS should preclude such approaches -- if anything, it should  
encourage them -- but we don't want to require them.

> So I would be interesting to see the TEP if it is going to be  
> released for comments before coding is finished.

Well, coding is never really finished. :) Kevin is improving the code  
base already, based on some comments John Regehr provided.

Phil