[Tinyos-devel] Problem with ArbiterP - ResourceDefaultOwner.isOwner()

[Kevin Klues]

No, you're definitely right.  This is a problem.  I"ll commit a fix
soon and let you know.

Kevin

On Nov 1, 2007 10:31 PM, Kevin Klues <klueska at gmail.com> wrote:
> Hmmm... I'll need to look into this.  The read request shouldn't put
> the arbiter into a state of RES_GRANTING right away, but rather queue
> the request until the power manager has released it.  In this way, the
> isOwner() command will return TRUE since the PowerManager is still the
> owner and the arbiter is still in the RES_CONTROLLED state.  Like I
> said, I need to take a look.
>
> Kevin
>
>
> On Nov 1, 2007 8:16 PM, Ken Bannister <regkb at deru.com> wrote:
> > I have found an incompatibility with the latest change to ArbiterP's
> > implementation of ResourceDefaultOwner.isOwner(). The issue occurs when
> > trying to use a Sensirion Sht11 sensor with the SensirionSht11C component.
> >
> > The problem is a consequence of the wiring in HplSensirionSht11C. It
> > allocates an FcfsArbiterC and wires
> > SplitControlPowerManagerC.ResourceDefaultOwner to the Arbiter.
> >
> > When the higher level SensirionSht11C handles a read request it first
> > requests the resource, which puts ArbiterP in RES_GRANTING state and then
> > the ResourceDefaultOwner.requested() event is triggered. PowerManagerP's
> > response eventually executes:
> >
> >    event void SplitControl.startDone(error_t error) {
> >      if(call ResourceDefaultOwner.isOwner())
> >        call ResourceDefaultOwner.release();
> >    }
> >
> > At this point isOwner() returns false since it's no longer in RES_CONTROLLED
> > state. I have worked around the problem by modifying the implementation of
> > isOwner() to:
> >
> >      atomic
> >      return state == RES_CONTROLLED
> >              || (resId == default_owner_id
> >                  && (state == RES_GRANTING || state == RES_IMM_GRANTING));
> >
> >
> > There seems to be several scenarios when isOwner() is called, and I don't
> > have the experience to suggest a more comprehensive solution.
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at Millennium.Berkeley.EDU
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
>
>
>
> --
> ~Kevin
>



-- 
~Kevin