As the code currently is, you're right, if start or stop ever fails, then there is a chance for lock up. Doing a task repost after checking return conditions shuld fix this problem. As you say though, if FAIL is returned indefinitely, then the task will be reposted forever, but then again you've got other problems if FAIL is perpetually being returned when trying to start or stop a device..... I'll check in the fix.
Kevin On Thu, May 1, 2008 at 11:55 AM, Dimas Abreu Dutra <[EMAIL PROTECTED]> wrote: > Hello again, > > I re-read the code and see now that EBUSY should only be returned by > SplitControl.stop() on PowerManagerP if a release() command is issued before > a granted() is signaled, which I believe should not occur. And the stopping > condition variable prevents the EBUSY from being returned by > SplitControl.start() . So PowerManagerP is indeed EBUSY - proof. My > component should not have returned that, and it isn't anymore, I changed it > to return FAIL. > > Anyway, FAILs can be returned at any time and if it happens the component > PowerManagerP will lock forever, specially in the stop, since if happens on > the start a second call to requested() can "unfreeze" the component. > > Also, if there is a startDone(FAIL), the granted will be signaled but the > component won't be on. This hasn't happened with me, but could happen to > someone, and if it does PowerManagerP would not behave as stated in TEP115. > All this could be fixed with checks to the return value and re-posting the > startTask or stopTask if FAIL occurs. The caveat of this approach is if FAIL > is returned forever (a hardware error occured, or something like it) the > task will be always run with no need, but I think this would be a rare case. > > EALREADY, also, should not happen if the ResourceDefaultOwner interface is > used correctly. > > ~Dimas~ > > > > On Thu, May 1, 2008 at 2:25 PM, Philip Levis <[EMAIL PROTECTED]> wrote: > > > > > > > On May 1, 2008, at 10:16 AM, Kevin Klues wrote: > > > > > I doesnt provide start and stop though. It only uses it. Return EBUSY > to whom? > > > > > > Kevin > > > > > > > Uh, the point is that SplitControl.stop should only return EBUSY if the > underlying component is in the starting state. So the question is whether > the observed lockup is due to > > > > 1) PowerManagerP is calling stop() when the component is in the starting > state (PowerManagerP is not managing state transitions correctly), > > 2) more than one component is wired to SplitControl (violates wire-once > and power management), or > > 3) the underlying component is not compliant with TEP 115. > > > > Phil > > > > -- ~Kevin _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
