lockset stalls?
TinkersALot
Posts: 535
Hi -- Here is what I am doing (wrong?).
1. I have an object "B" that is started in a cog that calls "locknew" in its "start" function. All this is fine -- no worries
2. "B" has a long variable that is declared in the VAR block for the object.
3. The object "B" has a "getter" and a "setter" for the variable that uses "repeat until not lockset..." , then variable access (read or write), followed by "lockclr"
4. This variable should be "periodically set" by the "initial program" running in cog 0 it attempts to do this by using the "setter" described above.
What I think I am seeing are exceedingly long stalls (on the order of tens of seconds") when the two cogs are running. If I disable the "set" from the cog 0 program, then the "B" object (running in its own cog) runs at full tilt -- so the code in the "getter" and "setter" should be good in so far as how they lock is treated. So what could account for these stalls? Is there something special that needs to be done with regard to how this "shared memory" is declared ?
Any hints would be greatly appreciated.
1. I have an object "B" that is started in a cog that calls "locknew" in its "start" function. All this is fine -- no worries
2. "B" has a long variable that is declared in the VAR block for the object.
3. The object "B" has a "getter" and a "setter" for the variable that uses "repeat until not lockset..." , then variable access (read or write), followed by "lockclr"
4. This variable should be "periodically set" by the "initial program" running in cog 0 it attempts to do this by using the "setter" described above.
What I think I am seeing are exceedingly long stalls (on the order of tens of seconds") when the two cogs are running. If I disable the "set" from the cog 0 program, then the "B" object (running in its own cog) runs at full tilt -- so the code in the "getter" and "setter" should be good in so far as how they lock is treated. So what could account for these stalls? Is there something special that needs to be done with regard to how this "shared memory" is declared ?
Any hints would be greatly appreciated.
Comments
This probably isn't the problem, but as I've recently discovered, a locknew does not guarantee a lock that is in the false (clear) state. Instead, it could be in either state.