[Tinyos-devel] Resource.isOwner() can return false information

[Kevin Klues]

Your'e right.  I didnt change this when I changed the rest before.
I've checked in the fix now.  Thanks for taking the time to track down
all these bugs ;-)

Kevin

On 9/7/07, Roman Lim <rlim at ee.ethz.ch> wrote:
> Hi Kevin
>
> I found, that in this new version, ResourceDefaultOwner.isOwner() does
> not work anymore, because the state is not BUSY, if the resource is
> owned by the default owner, so there must be some changes for:
>
> async command uint8_t ResourceDefaultOwner.isOwner() {
>      return call Resource.isOwner[default_owner_id]();
> }
>
> Roman
>
> Kevin Klues wrote:
> > The fix has now been checked in.
> >
> > Kevin
> >
> > On 8/24/07, Kevin Klues <klueska at gmail.com> wrote:
> >> Your right.  The problem is having the id set incorrectly between
> >> pending requests.    The fix you propose will do the trick.
> >> Alternatively, resId could be set to NO_RES just before posting the
> >> granted task.  I think your approach is better though, since under
> >> most circumstances it is unnecessary to actually change the resId
> >> between a release and granting a pending request.  The state of the
> >> arbiter prevents it from doing anything funky in the meantime.  Since
> >> resources are released more often than isOwner() is called, it makes
> >> sense to add the check on the state of the arbiter in the body of the
> >> isOwner() command rather than explicitly change the resId everytime a
> >> resource is released.  Plus, doing a comparison takes less cycles than
> >> doing an assignment.  Thanks for pointing out this bug.  I'll make the
> >> change today and check it into cvs.
> >>
> >> Kevin
> >>
> >> On 8/24/07, Roman Lim <rlim at ee.ethz.ch> wrote:
> >>> example case:
> >>> client0 requests resource
> >>> client1 requests resource
> >>> client0 gets the resource granted
> >>> client0 has a loop wherein it:
> >>>         *releases the resource on a certain condition
> >>>         *exits the loop, if the resource was released (e.g. isOwner() returns
> >>> false)
> >>>
> >>> in this case, isOwner() will always return 'true' because in the current
> >>> implementation, 'resId' is changed in a task that will run after the
> >>> loop of client0 is finished:
> >>> in the case of SimpleArbiter, 'resId' is only set to NO_RES, if no
> >>> request is pending upon release. In the other case, 'resId' remains
> >>> client0, until the granted task gets executed (after that, it changes to
> >>> client1).
> >>> in the case of normal Arbiters 'resId' is also only set to the default
> >>> owner's id, if no request is pending at the time when the resource was
> >>> released.
> >>>
> >>> by my understanding, isOwner() should return false after the command
> >>> release() has been called.
> >>>
> >>> roman
> >>>
> >>> Kevin Klues wrote:
> >>>> Can you give a use case where this actually occurs?  I understand your
> >>>> concern... as well as your proposed solution,but as it is implemented
> >>>> now, upon release 'resId' is either set to NO_RES in the case of
> >>>> SimpleArbiters or the resource is handed over to its default owner in
> >>>> the case of normal Arbiters.  I'm not sure under what circumstances it
> >>>> would falsely return TRUE.
> >>>>
> >>>> Kevin
> >>>>
> >>>> On 8/23/07, Roman Lim <rlim at ee.ethz.ch> wrote:
> >>>>> Hi
> >>>>> I just had a case, where I found a call to Resource.isOwner() returning
> >>>>> TRUE, even when the Resource was just released.
> >>>>>
> >>>>> If there is a request pending while releasing the resource, resId does
> >>>>> not get assigned another id immediately, but only when the granted task
> >>>>> gets executed. A call to Resource.isOwner() between release and granted
> >>>>> will therefore return true for the component that just released the
> >>>>> resource, because isOwner just compares the id of the caller and the
> >>>>> resId to determine the return value.
> >>>>>
> >>>>> I suggest to check the state of the arbiter in the isOwner() command,
> >>>>> too and return true, if id==resId and state==RES_BUSY.
> >>>>>
> >>>>> Roman
> >>>>> _______________________________________________
> >>>>> Tinyos-devel mailing list
> >>>>> Tinyos-devel at Millennium.Berkeley.EDU
> >>>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >>>>>
> >>>>
> >>>
> >>
> >> --
> >> ~Kevin
> >>
> >
> >
>
>


-- 
~Kevin