LOCKSET question

epmoyer · 2007-09-05 15:31

Last night I was coding a LOCKSET around a critical section in each of two ASM modules running on different cogs. The LOCKSET code in both modules is

:lock1            lockset LOCK_ID wc
            if_c  jmp  #:lock1
                  .
                  . 
                  .
                  lockclr LOCK_ID

                  .
                  . 
                  .

LOCK_ID           long 0

The second module goes into a loop between the lockset/lockclr and talks to an external device for a while (i.e. wiggles a bunch of IO pins), but makes no access to Main RAM, and does no other semaphore operations between the lockset and lockclr (and for that matter, no hub operations). The first module does nothing between the lock/lockclr except a single NOP. When I was debugging last night it sure seemed as though the fact that the first module was hammering on the semaphore (trying to get it) was causing the second module to run much slower as it executed the code between its lockset and lockclr. Eventually I put the problem aside and went to bed, but it has been bugging me all morning and I won't get a chance to chase it down again until tonight.

My question is this:

Am I correct in thinking that a LOCKSET loop running on one cog (i.e. one cog hamming on lockset trying to get a semaphore which is currently locked by another cog) should have no effect on the performance of code running on another cog? I would have expected this to be true even if the other cog was accessing Main RAM.

Again, I have not done enough debugging/testing to confirm what is really happening, but I just wanted to make sure that my expectation of the deterministic nature of instruction execution was correct before I go spinning my wheels chasing this bug tonight. I'm hoping I just missed something stupid, but if there is a cross-cog performance hit for hammering on lockset then I need to rethink what I'm doing.

I'm not using LOCKNEW/LOCKRET yet, but I am running a "closed" software system with no other semaphores in use. My understanding is that LOCKNEW/LOCKRET is just a number allocation mechanism and does no other magic.

Thanks in advance

Kaio · 2007-09-05 15:49

epmoyer,

I did not use semaphores on the Propeller yet. But from reading the manual (p. 231/232) I think you must first use LOCKNEW to allocate a semaphore before you can try to get a lock via LOCKSET.

I would also expect that a LOCKSET does not effect the speed of other Cogs.

deSilva · 2007-09-05 18:33

(1) I should also expect the LOCKNEW to be just a bounded counter; but I also should expect it to reset the lock, if left set after a LOCKRET... Or LOCKREST resets it?

And thinking a little bit longer... It cannot be such easy, as any LOCK can be returned, and a LOCKNEW has to find a free one. So using an unattached LOCK COULD have peculiar effects

(2) The fast lock from the first COG can enforce a second try of each lock in many cases in the second COG which will systematically add 31 ticks to the loop...

Post Edited (deSilva) : 9/5/2007 9:14:40 PM GMT

epmoyer · 2007-09-06 05:54

After much wailing and gnashing of teeth I found the problem, and it wasn't a lock performance issue after all. I had been precomputing a waitcnt value to keep a service loop synchronized and when I added the LOCKSET loop I ended up waiting so long to get the lock that by the time I made it to the watcnt the system counter had passed my target value and everything hung until the system counter came around again.

I'm glad that's over with [noparse]:)[/noparse]

LOCKSET question

Comments