LOCKTRY instruction problem?
dartof
Posts: 8
in Propeller 2
I'm having a problem getting the LOCKTRY instruction to work. No matter what I do, I can never get it to return with the carry set, indicating a lock has been acquired.
I am running in Pnut, which is compiling the instruction correctly, and downloading to a P2ES board, rev-B cpu, with the onboard pin 56 LED being used to display the carry bit.
The LOCKNEW instruction, however, does work. I can acquire any lock from $0 to $F with no problem. And, when I check out all 16 locks, then try a 17th, it returns with
the carry set, like it's supposed to.
What am I doing wrong?
'test locktry instruction
DAT org 0
i1 drvh #56
locktry #$0 wc
outc #56
inf jmp #inf
I am running in Pnut, which is compiling the instruction correctly, and downloading to a P2ES board, rev-B cpu, with the onboard pin 56 LED being used to display the carry bit.
The LOCKNEW instruction, however, does work. I can acquire any lock from $0 to $F with no problem. And, when I check out all 16 locks, then try a 17th, it returns with
the carry set, like it's supposed to.
What am I doing wrong?
Comments
try for carry NOT set
Mike
LOCKREL D WC will put the current owner in D and the captured state into C.
It looks like LOCKTRY only returns C=1 when the cog already has the lock.
Running this test code through my debugger gave the following results. Need to dig a bit deeper....
After further test it appears that LOCKTRY won't grab a free lock but can STEAL an already captured lock from other cogs!
The LOCKREL instruction is not working properly also.
It only returns the owner and state of a lock captured with LOCKTRY not LOCKNEW.
if the locks work similar to P1, I think it works as follows: locks are actually two 16-bit registers. One register manages "ownership" and one manages "held locks". LOCKNEW and LOCKNEW and LOCKRET work on the first register, while LOCKTRY and LOCKREL work on the second register. The idea goes something like this:
Cog A calls LOCKNEW to get an "available lock" (from the first register)
Cog A then shares that index with Cog B that it wants to use the locks with.
Cog A and Cog B use LOCKTRY and LOCKREL to coordinate (via the second register)
Optionally, Cog A may call LOCKRET to free up a lock for others to use.
In this scheme, everything is strictly cooperative. In other words, there is nothing stopping cogs from using LOCKTRY and LOCKREL for any of the locks, except by a priori agreement (either hardcoded lock indexes or the use of LOCKNEW/LOCKRET to dynamically get an index). Similarly, there's nothing stopping from Cog B calling LOCKRET for a lock that was assigned to Cog A by LOCKNEW. The presumption is that the software is written "correctly" and follows the LOCKNEW->repeat(LOCKTRY->LOCKREL)->LOCKRET pattern.
Given this, LOCKTRY should not be able to steal from the same index where another LOCKTRY has already succeeded (but LOCKREL has not yet been called). But it can definitely grab the lock for any other lock, regardless of calls to LOCKNEW.
Does this match what you are seeing?
Under this new scheme, any cog that shuts down or restarts automatically releases any lock it has. This was all done with future debugging in mind.
contrary to what the doc's say: "LOCKs can be used directly, without the hub allocating them..."
I've also found that any cog can issue a LOCKNEW or LOCKRET for any lock at any time-- there is no exclusion to which cog can do a LOCKRET.
Once a LOCKNEW is issued and the lock number attained, LOCKTRY and LOCKREL do work as expected.
Here is the code I used to experiment with:
(I have LEDS connected to the P31-P0 port pins- great for debugging)
So, I guess the only way to use the locks directly is just to LOCKNEW all the locks you need and leave them checked out.
I interpreted this quote in the docs to mean that I can nominate my own hardcoded indexes using LOCKTRY.
My use of the word "STEAL" was probably misleading to indicate the use of LOCKNEW first to allocate a lock.
I just got rid of the offending sentence in the Doc file.
No worries Chip.
Docs are cheaper to fix than silicon!
https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/edit#heading=h.g9zh968b50bv
In spin we did whereas in spin2 I've put this in the P2 Tricks and Traps thread too.
Postedit: Fixed as per Eric's suggestion
Is there some significance to using "cardLockID - 1" instead of "LockID"? I assume not, but this could very well become a source of confusion to new users who think that besides the NOT difference one must also subtract one from the lock ID in Spin2.
I changed the first but forgot to change the second