[Tinyos Core WG] TOSThreads TEP

[John Regehr]

This is cool Kevin.

Am I missing something or are the files in tos/lib/tosthreads/interfaces 
not there?

If I understand correctly, you have TinyOS running on it own stack but 
interrupts falling onto the current thread stack?  Can you justify that 
design decision?

A simpler approach would be to not run TinyOS in a thread. Then you 
would not need to hack the interrupt epilogue.  Rather, the TinyOS task 
scheduler would just call into the thread dispatcher when the task queue 
becomes empty.  There is no loss of generality as long as you want 
TinyOS at the maximum priority.  Of course it costs RAM to run TinyOS 
tasks on the current thread stack.

Another alternate approach would be to have a separate stack for 
interrupts+TinyOS.  In this case there is no need to reserve stack RAM 
for interrupts on every thread stack (well, you do need to reserve 1 or 
2 bytes).  For mica-type platforms I think this is the right design-- 
and you might as well go all the way and do the right thing if you're 
hacking the prologue/epilogue anyway.

A suggestion that I keep making when reviewing papers about adding 
threads to TinyOS applies here as well: if you want good adoption of 
this, you will want to extend nesC's concurrency model to include 
thread-based concurrency.  First, the race detector needs to be fixed. 
Second, are atomic sections going to still disable interrupts, or will 
they be compiled into thread locks when they do not involve data touched 
by interrupts?  Of course any atomic that disables interrupts cannot 
include a blocking call.  We want to help people avoid deadlocks.  Etc. 
  There is plenty of fun if your inclination runs towards compiler type 
stuff.  David Gay would perhaps find this work entertaining, and I 
certainly would.

I'd add a priority argument to the thread create call; people will 
expect this.

What's the use case for dynamic threads?

John