I have noticed that resource.granted() is signaled at startup.If ResourceRequested.requested() is signaled to a module that does not own the resource, i think that is a bug
On Sun, Sep 14, 2014 at 3:32 PM, Eric Decker <[email protected]> wrote: > > > On Sun, Sep 14, 2014 at 11:16 AM, Roadstar Runner <[email protected]> > wrote: > >> I have also noticed some strange behavior with ResourceDefaultOwner. If a >> module calls Resource.request() in Boot.booted(), >> ResourceDefaultOwner.requested() >> is signaled before the resource is granted to the default owner >> > > by default on power up, after initialization, the default owner owns the > resource, by default. It doesn't actually get granted on the way up. > > >> >> On Sun, Sep 14, 2014 at 12:59 PM, Eric Decker <[email protected]> wrote: >> >>> >>> >>> On Sun, Sep 14, 2014 at 7:28 AM, Roadstar Runner <[email protected] >>> > wrote: >>> >>>> But if thee is no default owner for the resource, then the system could >>>> be locked because module 2 will never get the resource. I was under the >>>> impression that if a call to Resouce.request() returns SUCCESS , then >>>> either granted or requested will have to be signaled so that the resource >>>> is actually shared. >>>> >>> >>> It is my understanding that if Resource.request() returns SUCCESS than >>> one is guaranteed that .granted will eventually be signalled. (Not either >>> .granted or .requested). >>> >>> .requested will only be delivered after a module owns a resource and >>> another module requests the resource. >>> >>> Also if module2 has the resource, releases it and immediately requests >>>> it again before module 1 is granted the resource...we will lock up the >>>> system >>>> >>> >>> I have to verify this (currently working on it), but what currently >>> happens (with FCFSArbiter) is Module2 will be granted the resource again. >>> So the system doesn't lock up but the proper behaviour doesn't occur. >>> Queue discipline isn't properly honored. >>> >>> >>> -- >>> Eric B. Decker >>> Senior (over 50 :-) Researcher >>> >>> >> > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
