That implies it in certain cases module 1 which would like to hold on to the resource till another module requests it, will never release the resource as requested is never signaled ( even tho module 2 has requested it) . This could cause serious resource sharing issues where multiple modules are vying for a resource.
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 > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
