[Tinyos Core WG] TOSThreads TEP

[Kevin Klues]

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

None of the files are in there yet.  They are in place on my local
checkout, but people said they wanted to see a TEP before pushing the
changes into the tree.  Everything is ready to go though, just need
the word.

> 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?

Simplicity I guess.  There is no true motivation for this necessarily,
other than it requires one less context switch per interrupt.  I
thought of bundling the TInyOS stack and the stack taht interrupts run
on together,  so that each thread didn't have to pay the RAM cost of
handling the interrupts, but I never got it fully implemented.  As it
currently stands, every thread has to have stack space allocated to
handle both their own call stack, plus the maximum depth of the
interrupt call stack -- thus duplicating RAM usage for the interrupts
across all threads .  In the alternate approach I mentioned, you would
onwly pay this cost once, and each thread would only need to allocate
space for its own call stack.

> 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.

Even in your scenario, you would still need to hack the epilogue I
think.  You would still need a way to tell the tasks to start running
after the interrupt handler has completed.  Otherwise it would just
return to the point where the interrupted thread was interrupted.

> 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.

I think this is the same as what I was mentioning before.  And I
agree, this is probably the right approach to take in the long run
given the memory constraints on these things.

> 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 honestly haven't put much thought into any of this.  I guess sort of
a basic assumption I was making is that atomics would NOT be allowed
inside thread based code.  Deadlock detection is something that is
probably pretty critical.

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

I don't have an argument for priority because there are no priorities
in the current implementation..... Does it make sense to have the
argument even if its not supported?  Or are you suggesting I add
functionality for priority based scheduling?

> What's the use case for dynamic threads?

The primary motivation for dynamic threads are for supporting
dynamically loadable binaries at runtime.

>
> John
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>



-- 
~Kevin