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
>[email protected]
>https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
