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

[Roman Lim]

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
>>
> 
>