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

Reply via email to