[Tinyos-help] Re: [Question] about task in book "TinyOS Programming"

[Philip Levis]

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