[Tinyos-devel] Bug in Resource.request interaction with ResourceRequested.requested

[Kevin Klues]

Because this should have been assigned via the change that I made
anyway for consistency.  It was a bug, not to set it this way.

Kevin

On Tue, Aug 12, 2008 at 10:51 PM, Eric Decker <cire831 at gmail.com> wrote:
>
> Works.
> Why not the check for RES_BUSY in request?
> eric
>
> On Tue, Aug 12, 2008 at 12:36 AM, Kevin Klues <klueska at gmail.com> wrote:
>>
>> I agree this is in fact a bug.  I think the correct solution would be
>> to add one line inside of resource.release() for resId=NO_RES while in
>> the process of granting the resource.  Can you try this out and let me
>> know if it fixes the problem.  I'll check it in if you can verify that
>> it solves it.
>>
>> inside Resource.release()
>>
>>        if(call Queue.isEmpty() == FALSE) {
>>          reqResId = call Queue.dequeue();
>>          resId = NO_RES;
>>          state = RES_GRANTING;
>>          post grantedTask();
>>          call ResourceConfigure.unconfigure[id]();
>>        }
>>
>> Kevin
>>
>> On Mon, Aug 11, 2008 at 5:21 PM, Eric Decker <cire831 at gmail.com> wrote:
>> > I am making heavy use of arbitration in a T2 based mote.  I've
>> > discovered
>> > what looks
>> > like incorrect behaviour.  The code looks like:
>> > =>async command error_t Resource.request[uint8_t id]() {
>> >     signal ResourceRequested.requested[resId]();
>> >     atomic {
>> >       if(state == RES_CONTROLLED) {
>> >         state = RES_GRANTING;
>> >         reqResId = id;
>> >       }
>> >       else return call Queue.enqueue(id);
>> >     }
>> >     signal ResourceDefaultOwner.requested();
>> >     return SUCCESS;
>> >   }
>> >
>> > The problem is ResourceRequested.requested[resId]() gets signaled
>> > no matter what.  "resId" holds the value of the last holder of the
>> > resource
>> > it doesn't get modified when a resource owner does a release.
>> > I would assert that a ResourceRequested.requested shouldn't be signaled
>> > unless the resource is actively owned by resId.  ie.  signal only if
>> > state
>> > == RES_BUSY.
>> > So if a resource owner does a release it is possible (Resource.request
>> > is
>> > async) for a
>> > request to come in.  If ResourceRequested.requested is signaled, I
>> > assert
>> > that
>> > this is wrong.
>> > This can be protected inside of the ResourceRequested.requested
>> > event by checking for ownership but I think it would be cleaner to check
>> > for
>> > RES_BUSY
>> > inside of Resource.request.  I would assert ResourceRequested.requested
>> > should
>> > only be signaled when the resource is owned and a new request comes in.
>> >  It
>> > only should
>> > be signaled to the current owner.
>> > I observed the failure when executing the following code:
>> >         call UARTResource.release();
>> >         call GPSMsg.reset();
>> >         call GPSTimer.startOneShot(DT_GPS_MAX_REQUEST_TO);
>> >         call UARTResource.request();
>> > Even though we do the release,  when the request is executed, I observe
>> > that
>> > UARTResourceRequested.requested is getting signalled which seems odd.
>> > thoughts,
>> > eric
>> >
>> > --
>> > Eric B. Decker
>> > Senior (over 50 :-) Researcher
>> > Autonomous Systems Lab
>> > Jack Baskin School of Engineering
>> > UCSC
>> >
>> >
>>
>>
>>
>> --
>> ~Kevin
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
>



-- 
~Kevin