i am re investigating whether the initial granted that was signaled, was
probably due to another resource acquiring and then releasing the resource.
In the meantime i am working on another strange behavior i noticed

If ResourceDefaultOwner is the current owner, a call to  call
ArbiterInfo.inUse()  returns FALSE, however if another module has requested
the resource, a call  to  ArbiterInfo.inUse() returns TRUE even though
ResourceDefaultOwner  has not yet released the resource.

I have been discussing this with Eric, so Eric might have some more insight


On Mon, Sep 15, 2014 at 3:36 AM, Martin Cerveny <mar...@c-home.cz> wrote:

> Hello.
>
> (this may be irrelevant hint)
>
> On Sun, 14 Sep 2014, Roadstar Runner wrote:
>
>> I have noticed that resource.granted() is signaled at startup.
>>
>
> What kind of startup & what kind of module ?
> There is still unresolved bug for modules, that call request in
> Software.Init():
>
> https://github.com/tinyos/tinyos-main/blob/master/tos/
> chips/rf230/RF230DriverHwAckP.nc#L247
>
> This is buggy, that it can be called to uninitialized resource (you have
> only 50% to work), the initialization order of modules
> (SoftwareInit.init()) is undefined :-)
>
> https://github.com/tinyos/tinyos-main/issues/134
>
> If this is your issue, try simple fix:
>
> https://www.mail-archive.com/tinyos-help%40millennium.
> berkeley.edu/msg40413.html
>
> M.C>
>
>
>  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 <cire...@gmail.com> wrote:
>>
>>
>>       On Sun, Sep 14, 2014 at 11:16 AM, Roadstar Runner <
>> redstripe...@gmail.com> 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.
>>
>>       [cleardot.gif]
>>
>> On Sun, Sep 14, 2014 at 12:59 PM, Eric Decker <cire...@gmail.com> wrote:
>>
>>
>>       On Sun, Sep 14, 2014 at 7:28 AM, Roadstar Runner <
>> redstripe...@gmail.com> 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
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to