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

[Kevin Klues]

More comments to come, but I wanted to address your very last one
first. i.e. this one...

> I for one, still believe in the basic soundness of the event-driven model
> even for user/app code. In this sense, I personally have a problem with a
> threading solution that is not completely optional. I don't want to have a
> thread scheduler being run by default. I don't want to pay a price for
> wakeupThread on every interrupt. With all of those things by default in, for
> me this would not be TinyOS anymore.

So I didn't go into the details in teh TEP, but using tosthreads and
everything that comes with it would in fact be completely optional.
The plan (which is is already in place and working) is to allow
applications to be compiled with threading enabled by running
something like the following from the command line:

$ make telosb threads
or
$ make telosb cthreads

the 'threads' target for normal nesC based applications, and
'cthreads' for c based applications.  Specifying these targets will
pull in code from a 'tos/lib/tosthreads' directory and define a
THREADS preprocessor variable for ifdefing any necessary code in the
standard tinyos tree.  In the case of the PlatformInterruptC component
described in 'tos/system' will contain a default implementation which
does absolutely nothing, and the one implementing the true interrupt
post amble stuff will shadow it when compiling for threads/

Kevin

On Tue, May 20, 2008 at 3:41 PM, Vlado Handziski
<handzisk at tkn.tu-berlin.de> wrote:
> Thanks for posting this Kevin. I think it is very important that we have a
> high quality technical documentation to support us in discussing the
> proposal. That's why I suggested that writing a proper TEP would be very
> helpful. I like to congratulate you on the great effort. Please take my
> comments below not as critique on the your design or implementation, but as
> an attempt to start a more high level discussion on the direction we want to
> see TinyOS go, before plunging in the technical details about the actual
> proposal. I sounded most of my concerns directly with you after the
> presentation here at TUB, but now that we have an official proposal, I would
> like to voice some of them on this forum too.
>
> I think that the name of the TEP is misleading. What is on the table here is
> much more then a simple threading library. This is not a simple "add on",
> but a fundamental redefinition of the basic premises of the OS. You are not
> proposing a threading add on to TinyOS, you are proposing a new thread-based
> OS that wants to run TinyOS as a kernel thread.
>
> The component-based model combined with the even-driven nature and the two
> concurrency classes have defined what TinyOS means ever since the "System
> Architecture Directions" paper. TinyOS never tried to be everything to
> everyone, it was designed based on a specific set of assumptions about what
> is important in the (mote-class) networked embedded systems. We all know
> that this simplicity has its price. The split-phase model, having to keep
> eye on the duration of the tasks, etc. It is true that the TinyOS model is
> sometimes very hard for the new users to grok. It is also true that in some
> situations it is hard to naturally decompose the processing in short task
> chunks (crypto routines, etc.).
>
> I understand that threading is seen by many as the natural solution for
> these problems, people coming from the PC world are used to them, they allow
> programmers to forget about concurrency, etc. I think that they just give a
> false sense of simplicity, but I can see how people might want to use them
> with TinyOS also. Many papers have been written on this, yours is the latest
> one, so clearly there is some push to go in this direction. But if we start
> walking down that path, where do we stop? After matching the features of
> Mantis OS and SOS, what's next? Making TinyOS a general purpose OS?
>
> I for one, still believe in the basic soundness of the event-driven model
> even for user/app code. In this sense, I personally have a problem with a
> threading solution that is not completely optional. I don't want to have a
> thread scheduler being run by default. I don't want to pay a price for
> wakeupThread on every interrupt. With all of those things by default in, for
> me this would not be TinyOS anymore.
>
> Vlado
>
>
> On Tue, May 20, 2008 at 9:34 AM, Kevin Klues <klueska at gmail.com> wrote:
>>
>> Attached.
>>
>> --
>> ~Kevin
>>
>> _______________________________________________
>> 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