is using SPIN-LOCK-Commands REALLY 100% mutually exclusive ?

StefanL38

Hello,

i'm thinking about the LOCK-commands like LOCKNEW, LOCKSET etc.

for a single long it is clear that the access to a single long is really mutually exclusive managed by the hub.

But what about larger amounts of memory used in SPIN ?


If i try to imagine how the LOCK-Commands work i think it is this way:

If two different cogs want to share the same HUB-RAM-Memoryarea and both could read/write to this memoryarea

i have to code a LOCK

Now if it happens that cog Nr. "0" has just READ the condition "if locked" and right AFTER READING
the HUB-RAM access is given to cog Nr. "1" and it happens that the SPIN-Code of Cog Nr. "1" is already
AFTER the READING "if locked" and starts setting the lock and then writes to the memoryarea
cog Nr. "0" is THINKING the lock is unlocked but just because of the "bad timing" between the two
SPIN-programs and which line of code both are executing both cogs start writing and the data crashes

Is my understandig right or am i missing something ?

I know it will not happen very often but it COULD happen !
Interpreting a single SPIN-commands take quite an amount of cycles and in the meantime the hub is
spinning around several times.

If it is a problem coding this way how could it be done otherwise but not by coding an ABSOLUT SEQUENTIAL access to the memomyarea ?

One Idea i have about this is to have bufferareas

The first byte of the bufferareay is the "lock"-Byte
wait for the first byte having status "unlocked"
then this byte is set to status "locked" at first by a movelong-command

then all the other bytes where written into the buffer
AFTER finishing writing byte 2-n the first byte is set to status "unlocked"

another cog runs a loop where he copies - in a sequential manner - the bufferarea to the shared memory area


best regards

Stefan

Jasper_M

The lock commands are 100% mutually exclusive.
Hope this example clears it out a little bit.

   repeat while lockset(locknumber)
    'LOCKSET returns lock's previous state - one if it is not free. Also, two locksets cannot happen
    'simultaneously because it is a HUB operation and two cogs cannot access the hub simultaneously.
    'So if the lock is taken by another cog, this loop waits until it clears it. when that happens, lockset 
    'SIMULTANEOUSLY - ON THE SAME HUBOP - returns 0 and sets the lock.
   [noparse][[/noparse]DO THE LOCKED CODE] '(Not in the loop, but after it)
   lockclr(locknumber)

hippy

As per Jasper_M.

The reason locks are atomic / 100% mutually exclusive is that, although Spin is an
interpreter, the interpreter itself uses the PASM LockSet opcode to give the Spin
program its desired effect.

Two Spin programs being interpreted are not mutually exclusive while the Spin LockSet
command is being interpreted until the interpreter executes the PASM LockSet but at
that point they are and thus it works.

Even if both Spin interpreters came to execute the PASM LockSet at the very same
time, the Hub spinning round will ensure only one gets to execute.

StefanL38

hello,

thanks for the explanation and the example.
maybe this seems penetrant to asking again, but english is not my native language (that's german)

Just to ensure that i understand it right: the PASM-LOCKSET-command does in ONE STEP
reading the current status of the lock AND if the status is "unlocked" change status to "locked"
WITHIN ONE access-"permission" of the HUB ?

Or otherwise described:
the PASM-LOCKSET-command reads (and if unlocked) writes the lock-status within ONE accesspermission given by the hub
so that the accesspermission to the other cogs is ONLY given to the other cogs AFTER FINISHING setting status to "locked" ?

i don't need a deterministic order of the shared-ram-access. It doesn't matter if cog 1 or cog 2 gets access first so it is enough
that it is locked 100% surely to avoid datacrashing

best regards

Stefan

Mike Green

Yes. The LOCKSET instruction tests the status of the specified lock and sets it to "locked" in one indivisible step.

StefanL38

hello Mike,

thank you very much for the answer.
Your post is exemplary ideal: making everything clear with a few words.

to me it's always a pleasure to read your postings regardless of it's an answer to me or to somebody else.

best regards

Stefan