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

[Eric Decker]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080812/d5da830f/attachment.htm