[Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
On Jul 29, 2006, at 11:02 PM, Hui KANG wrote: Dr. Levis: After reading Section 4.4 about Tasks in your book, "TinyOS programming", I still have some problem. Please send questions to tinyos-help. That way everyone can benefit from the answers, and they are entered in the online archives for future users. 1: For the code example in pp 31, you said signalling an even from within a command is a bad idea, since it can cause call loops. But actually in this example, Read.readDone does not call Read.read again. So I think it will not cause a call loop. Am I correct? Correct. 2: Second, to prove there exists a call loop, you modify Read.readDone as in pp 32. Herein, it calls Read.read() in Read.readDone(). I agree that in this example call loop occurs. So the modified code in pp 33 post task void readDoneTask() to avoid the call loop. Two problems in this code example: (a) In this example, RawRead.readDone (should it be Read.readDone() ) actually does not call Read.read(). If the answer to 1 is yes, then it seems no improvement by using task. Both have the same effect. The the code example in pp 33 is not suitable to show the benefit of Task. Take a look at the code on page 34. The question is not whether the provider of Read calls Read.read in Read.readDone, but whether the *user* does. Please look at listing 4.12, entitled "Signal handler that can lead to an infinite loop." (b) If assuming that the code example in 33 posted Read.read() in RawRead.readDone, does task avoid the call loop? As said, task can run atomicly to other tasks. But it is possible that Read.read() preempt to the task. So the call loop still exists? No. Look at the next listing. 3: What is the difference between task and an ordinary function, like task void ProcessData() and void ProcessData(); I am a little bit confused. Thanks. A function executes immediately. A task executes later. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
Dr. Levis: There is some question I still can not understand fully. >> 2: Second, to prove there exists a call loop, you modify >> Read.readDone as >> in pp 32. >> Herein, it calls Read.read() in Read.readDone(). I agree that in this >> example >> call loop occurs. >> So the modified code in pp 33 post task void readDoneTask() to >> avoid the >> call loop. >> Two problems in this code example: >> (a) In this example, RawRead.readDone (should it be Read.readDone() ) >>actually does not call Read.read(). If the answer to 1 is yes, >> then it seems >> no improvement by using task. Both have the same effect. The the code >> example in >> pp 33 is not suitable to show the benefit of Task. > >Take a look at the code on page 34. The question is not whether the >provider of Read calls Read.read in Read.readDone, but whether the >*user* does. Please look at listing 4.12, entitled "Signal handler >that can lead to an infinite loop." > Yes, but in the code example in Listing 4.15( An improved implementation of PeriodicReaderC ), the PeriodicReaderC is the user of Read. It does not call Read.read(). So even we don't use task, call loop will not occur. So it is not suitable to show the benefit of task. >> >> (b) If assuming that the code example in 33 posted Read.read() in >> RawRead.readDone, >> does task avoid the call loop? As said, task can run atomicly to other >> tasks. But >> it is possible that Read.read() preempt to the task. So the call loop >> still exists? >> > >No. Look at the next listing. > I know that task can not preempt each other. Then can Read.read(), or other sync commands and events preempt to any task? > >> 3: What is the difference between task and an ordinary function, like >>task void ProcessData() and void ProcessData(); >> I am a little bit confused. Thanks. > >A function executes immediately. A task executes later. > >Phil > >___ >Tinyos-help mailing list >Tinyos-help@Millennium.Berkeley.EDU >https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
On Jul 31, 2006, at 9:16 AM, Hui KANG wrote:
Dr. Levis:
There is some question I still can not understand fully.
2: Second, to prove there exists a call loop, you modify
Read.readDone as
in pp 32.
Herein, it calls Read.read() in Read.readDone(). I agree that in
this
example
call loop occurs.
So the modified code in pp 33 post task void readDoneTask() to
avoid the
call loop.
Two problems in this code example:
(a) In this example, RawRead.readDone (should it be Read.readDone
() )
actually does not call Read.read(). If the answer to 1 is
yes,
then it seems
no improvement by using task. Both have the same effect. The the
code
example in
pp 33 is not suitable to show the benefit of Task.
Take a look at the code on page 34. The question is not whether the
provider of Read calls Read.read in Read.readDone, but whether the
*user* does. Please look at listing 4.12, entitled "Signal handler
that can lead to an infinite loop."
Yes, but in the code example in Listing 4.15( An improved
implementation
of
PeriodicReaderC ), the PeriodicReaderC is the user of
Read. It does not call Read.read(). So even we don't use task, call
loop
will
not occur. So it is not suitable to show the benefit of task.
I think you're confused about the call pattern being described.
The issue is this:
component A {
uses Read;
}
component B {
provides Read;
}
If component A does this:
event void Read.readDone() {
call Read.read();
}
and component B does this:
command void Read.read() {
signal Read.readDone();
}
then you will get an infinite loop, because there is a recursive call
chain:
B.Read.read signals
A.Read.readDone calls
B.Read.read signals
A.Read.readDone calls
B.Read.read signals ...
This happens because of the details of how PeriodicReaderC is
sampling its sensor and generating a filtered value.
The way to make sure this does not happen is to break the recursion:
B.Read.read posts
B.readDoneTask
returns
B.readDoneTask signals
A.Read.readDone calls
B.Read.read posts
B.readDoneTask
returns
B.readDoneTask signals...
I know that task can not preempt each other.
Then can Read.read(), or other sync commands and events preempt to any
task?
Read is sync, so Read runs in a task. Tasks cannot preempt one
another. Therefore Read.read cannot preempt another task.
Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
Dr. Levis:
I just noted that there is an updated version of this book in your
website (version June 28,2006).
After I downloaded it, I found there are some samll errors in the code
example we discussed.
1:Listing 4.11 on p.33,
"command error_t Read.read()" in the implementation of PeriodicReaderC
should be moved to the implemenation of FilterMagC. Because FilterMagC
provides the interface Read, while PeriodicReaderC uses it.
There is no loop in this code example.
2: Listing 4.15 on p. 35;
Similarly, the last two functions should be moved to the provider of the
interface of Read.
Also there is no loop in this code example, not because of using task but
no Rawread.read() being called in Rawread.Done(). That is why I said
this example is not suitable for illustrate the benefit of task. It
could be more clear if Rawread.read() was called in Rawread.done().
Could you take a look at them and make them more understandable? Thanks.
Regards,
Hui
On 8/1/2006, "Philip Levis" <[EMAIL PROTECTED]> wrote:
>On Jul 31, 2006, at 9:16 AM, Hui KANG wrote:
>
>>
>> Dr. Levis:
>>
>> There is some question I still can not understand fully.
>>
2: Second, to prove there exists a call loop, you modify
Read.readDone as
in pp 32.
Herein, it calls Read.read() in Read.readDone(). I agree that in
this
example
call loop occurs.
So the modified code in pp 33 post task void readDoneTask() to
avoid the
call loop.
Two problems in this code example:
(a) In this example, RawRead.readDone (should it be Read.readDone
() )
actually does not call Read.read(). If the answer to 1 is
yes,
then it seems
no improvement by using task. Both have the same effect. The the
code
example in
pp 33 is not suitable to show the benefit of Task.
>>>
>>> Take a look at the code on page 34. The question is not whether the
>>> provider of Read calls Read.read in Read.readDone, but whether the
>>> *user* does. Please look at listing 4.12, entitled "Signal handler
>>> that can lead to an infinite loop."
>>>
>> Yes, but in the code example in Listing 4.15( An improved
>> implementation
>> of
>> PeriodicReaderC ), the PeriodicReaderC is the user of
>> Read. It does not call Read.read(). So even we don't use task, call
>> loop
>> will
>> not occur. So it is not suitable to show the benefit of task.
>>
>
>I think you're confused about the call pattern being described.
>
>The issue is this:
>
>component A {
> uses Read;
>}
>
>component B {
> provides Read;
>}
>
>If component A does this:
>
>event void Read.readDone() {
> call Read.read();
>}
>
>and component B does this:
>
>command void Read.read() {
> signal Read.readDone();
>}
>
>then you will get an infinite loop, because there is a recursive call
>chain:
>
>B.Read.read signals
>A.Read.readDone calls
>B.Read.read signals
>A.Read.readDone calls
>B.Read.read signals ...
>
>This happens because of the details of how PeriodicReaderC is
>sampling its sensor and generating a filtered value.
>
>The way to make sure this does not happen is to break the recursion:
>
>B.Read.read posts
>B.readDoneTask
>returns
>
>B.readDoneTask signals
>A.Read.readDone calls
>B.Read.read posts
>B.readDoneTask
>returns
>
>B.readDoneTask signals...
>
>
>>>
>> I know that task can not preempt each other.
>> Then can Read.read(), or other sync commands and events preempt to any
>> task?
>
>Read is sync, so Read runs in a task. Tasks cannot preempt one
>another. Therefore Read.read cannot preempt another task.
>
>Phil
>___
>Tinyos-help mailing list
>Tinyos-help@Millennium.Berkeley.EDU
>https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
On Aug 1, 2006, at 6:46 PM, Hui KANG wrote: Dr. Levis: I just noted that there is an updated version of this book in your website (version June 28,2006). After I downloaded it, I found there are some samll errors in the code example we discussed. 1:Listing 4.11 on p.33, "command error_t Read.read()" in the implementation of PeriodicReaderC should be moved to the implemenation of FilterMagC. Because FilterMagC provides the interface Read, while PeriodicReaderC uses it. There is no loop in this code example. You are totally right! The implementation blocks are wrong. No wonder it was so confusing. My apologies. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
