Help with using locks

Penguin-fach

I have been trying to get the Propeller locks to work for me but so far no luck. From what I have read this should all be straightforward.

1. Check out a new lock with the locknew command

2. Use a helper method to pass the lock ID between objects

3. Use the lockset command to set the lock (or test if it is set)

4. Use the lockclr command to clear the lock (or test if it is clear)

5. Use the lockret command to return the lock when it is no longer required

I have used the attached files to play with a lock that will be used eventually to signal that an EEPROM is busy. However when I run my simple little top object, Test_EEPROM.spin, the lock always seems to be set no matter what. I have been working with the education kit to breadboard this but just can't get the locks to do anyhting sensible

What am I doing wrong?

Test_EEPROM.spin
I2C_EEPROM_Dummy.spin

T Chap

It may be good idea to include some debug code so you can see what the results are before trying to check for a TRUE. If you can't use the terminal to show the variable states, you may be able to find an unused LED to use in tests. Instead of looking for a TRUE for the debug tests, test for ie -1,0,1,2 etc and that way you can 'see' what the results really are in real time as you are testing for them with the lock commands.

kuroneko

Penguin-fach wrote: »

3. Use the lockset command to set the lock (or test if it is set)
4. Use the lockclr command to clear the lock (or test if it is clear)

Here is your issue. Either command affects the lock (no choice). As a side effect it also returns the previous state (un/locked). Meaning when you apparently test your lock with if lockset(ID) you can act on its previous lock state but you also set it, i.e. next loop run you'll read locked unless someone else cleared it (again). In short, there isn't a non-destructive way of reading the lock status. Have a look at the manual's lock command description for more info.

Clive Wakeham

Penguin-fach wrote: »

I have been trying to get the Propeller locks to work for me but so far no luck. From what I have read this should all be straightforward.

I have used the attached files to play with a lock that will be used eventually to signal that an EEPROM is busy. However when I run my simple little top object, Test_EEPROM.spin, the lock always seems to be set no matter what. I have been working with the education kit to breadboard this but just can't get the locks to do anyhting sensible

What am I doing wrong?

Test_EEPROM.spin
I2C_EEPROM_Dummy.spin

I think your problem is that the "EepromLockID" is set from inside the "InitEEPROM" method, which is launched from a COGNEW. You need to set the EepromLockID number from your main method otherwise you can't control the lock from outside the "InitEEPROM" method.

Have a look at my object 74C92Xbuffer2.0.spin, and you will see that the method that launches the COGNEW actually passes the value of the Lock SemID to the cognew. This allows the object launched with the Cognew to have the SemID as well as any other methods that need it to control access to certain memory locations.

Regards,

Cluso99

While I have not looked at your code, there other ways to use the prop without locks. In fact, while I have been programming the prop for a few years now, using lots of parallel cogs/code, I have never used locks, nor had the requirement to use them.
As a possible sugestion, take a look at how the FullDuplexSerial passes data via cyclic buffers (ignore the rest of the code because its quite complex). I cannot think offhand other good examples, so perhaps someone will chime in with some.

Penguin-fach

Cluso99 wrote: »

While I have not looked at your code, there other ways to use the prop without locks. In fact, while I have been programming the prop for a few years now, using lots of parallel cogs/code, I have never used locks, nor had the requirement to use them.
As a possible sugestion, take a look at how the FullDuplexSerial passes data via cyclic buffers (ignore the rest of the code because its quite complex). I cannot think offhand other good examples, so perhaps someone will chime in with some.

I have written a little more code to try and make sense of the locks and to be honest, the fact that testing the lock status also sets or clears the lock really cripples them in my view. There needs to be some sort of 'locktest' command that returns the lock state without modification.

I can use 'If...else' to test the lock status and clear or set as needed - that all works fine. However there are many circumstances where you would want code to simply hold until a lock is clear. A simple single-line repeat would seem to be the best way to do this but that just will not work with the lockset and lockclr commands. As soon as they are used in this way the temporal relationship is lost and the repeat statement essentially assumes control of the lock.

Any chance that a locktest function might appear in the command set? In my opinion it would transform the locks into a truly useful feature rather than something that seems to be underutilised and, I suspect, even actively avoided by many.

T Chap

I never use locks. Where there is a need to lock something out, it is usually a simple matter of setting a variable to 1 at the top of the code to protect, then back to 0 when done. 1 is locked, 0 is unlocked. If some object needs to access that lock-able item, just repeat while lockVar = 1

PUB lockablemethod
        lockvar := 1
        'write eeprom or whatever
        lockvar := 0

PUB AccessEeprom
       Repeat While lockvar == 1
       lockablemethod
       

Far simpler than checking out locks IMO. The only thing is that is multiple cogs are accessing the same eeprom, you need to share the address of the variable when launching cogs so they have the pointers available to access. The same var can be used in other instances of code that need to access the eeprom, with the same result.

Dave Hein

@Cluso, cyclic buffers work fine as long as there is only one writer and one reader. However, a locking mechanism is needed if more than one cog is writing to the buffer. Two cogs could be incrementing the head index at about the same time, which would cause a problem.

@Penguin, a test instruction would be nice. Currently, you need to use a hub location and a lock to implement the type of function you are describing.

@T Chap, your method could fail if two cogs are calling AccessEeprom at about the same time. Both cogs will take control of the EEPROM. You may not have seen any problems in your applications, but this method will not work for all applications.

MagIO2

I don't see a need for a locktest! Either you want the lock or not! The purpose of the lock is exactly to read, modify, write the lock-status in an atomic operation to assure that there is no way to have COG 1 read the lock, COG 2 read the lock at nearly the same time and then both 'think' that it is free!
In fact you can easily simulate a locktest by lockset directly followed by lockclear.

If you only want to test that a COG is doing something, a normal variable is enough.

The lockset is totally fine, because it does not wait for the lock, so a COG can decide to do something else in case it did not get the lock.

I have to say that I also never have used a lock so far, but each kind of application that needs consistent read/modify/write access from more than one COG to more complex data-structures than one byte, one word or one long will benefit from locking.

mindrobots

Does Phil's response in this http://forums.parallax.com/showthread.php?118775-How-to-use-Locks thread help any? It helped me make sense of the lock access/testing.