Lockset Question?

eldonb46

If multiple COGs are executing:

repeat until not lockset(SemID)

Is the order of COGs successful getting the lock deterministic?

Or, does the execution of the "repeat" code effectively randomize the results?


Thanks,
Eldon

Phil Pilgrim (PhiPi)

It's deterministic, but maybe not predictable -- IOW, from a practical standpoint, a crapshoot if other Spin cogs are vying for the same lock.

-Phil

jazzed

Phil Pilgrim (PhiPi) wrote: »

It's deterministic, but maybe not predictable ....

Precise but not accurate?

Phil Pilgrim (PhiPi)

Possibly even chaotic.

Dave Hein

The loop execute 5 Spin bytecodes, which take a total of 884 cycles per loop. The cog that gets the lock will be the first one that executes the lockset after another cog has executed a lockclr. Assuming that each cog entered the loop at a random time, the winning cog will be randomly selected. However, if all the cogs entered the loop at the same time, and the cog that executes the lockclr was syncronized with that event, then the same cog would always win.

Mark_T

The minimal PASM loop would be 8 cycles min for the lockset, 4 cycles for the loop back, but after the first attempt would be hub-synchronized to 16 cycle repeat and thus the order of cogs precisely determines the winner. Perhaps Spin should have had a lockclaim primitive that did this busy-wait in PASM? (called waitlock?)

Dave Hein

Yes, if you have a mix of Spin and PASM cogs trying to acquire the lock, the PASM cogs will get it most of the time. In some situations a more complex scheme may be needed to ensure that all of the cogs get their turn to access a common resource.

Phil Pilgrim (PhiPi)

A more "polite" way to code it would be that, if you don't get the lock, do a random timeout before retrying.

-Phil