How to tell how many LOCKs are currently in use?

ags

I'd like to know how many LOCKs are currently "allocated". In other words, of the 8 LOCKs available, how many times will LOCKNEW return a new lock ID?

A brute-force method is to call LOCKNEW, storing the returned ID each time, until it fails (returns -1). This would also require going through the stored lock IDs and releasing them with LOCKRET.

Is there another way?

Mike Green

There's no direct way to tell how many LOCKs are "allocated". Your brute-force method is the only way I know.

ags

Thanks for the reply, Mike. Based on your track record, I am confident you are correct. In the spirit of sharing, here's the hack I came up with to determine how many LOCKs are checked-out. I expect improvements are possible, but this does function and upon return the locks are all in the same state as before calling this method:

PRI NumUsedLocks | locks, id
  locks~
  repeat 8
    if (id:=locknew)=>0
      locks |= (1<<id)
  repeat id from 0 to 7
    if locks&1
      lockret(id)
      result++
    locks>>=1
  result := 8 - result

TinkersALot

well you could have a lock factory object. the lock factory would be the defacto place where locks are created (via a method call on the object). the object could then keep a count of the number of locks that it created.

Phil Pilgrim (PhiPi)

There are eight cogs and eight locks. A cog should never have to own more than one hardware lock. The reason is that a single hareware "master" lock can be use to control any number of software "slave" locks, which are simply shared resources like the other shared resources that locks manage. In fact, the Propeller could have gotten by with just one hardware lock, for which a universal lock object could be written to handle the locking and unlocking of multiple slave locks. However, that may have caused some throughput issues, so I'm glad there are eight locks available.

Anyway, the short answer is that with a properly-written program, you should never have to worry about how many hardware locks are available.

-Phil

ags

Phil:

Not sure if I agree, but not sure if I disagree either (re: one lock per cog max).

I think I have a valid reason to want to know how many locks are available (or used): I implemented this for debugging a bootloader that I eventually diagnosed as failing after multiple calls because it never checked-in locks.

Phil Pilgrim (PhiPi)

Well, okay. For debugging faulty code, lock usage would definitely be a handy statistic to know. But for normal programming, there's no good reason to use more than one hardware lock per cog, since you can use it to spawn as many slave locks as you need..

-Phil

ags

I didn't realize what you meant by "slave locks" in your first post until I re-read it (and you mentioned "spawn slave locks" in the second post - which clicked). So yes, with only one "hardware lock", used to provide exclusive access to what would in effect be an object to manage "software locks" I see how this would work. But as you also point out, there may be throughput issues (and I suspect it may be more susceptible to deadlock situations, but I that's just an intuition, I haven't thought through any concrete examples to prove or disprove that) and since there are 8 locks available, I figure might as well use them all. I can think of cases where a top object would use a lock to manage interaction between child objects (so the lock couldn't live in the child objects) and if there were multiple situations like this, the top object would therefore have a valid reason to have multiple locks - however implemented. The case I have in mind is something I need to address, so it's been banging around in the back of my head, but I don't yet have a concrete solution or design. I'm thinking of situations where I create an SPI bus with shared clock and data lines across multiple connected slaves. No slave knows about anyone else on the bus, but some bus management has to occur to avoid contention. This would be done with some form of locking, and control of the chip select lines. I've thought this would be an singleton object, included (referenced) by each slave object. Before any transaction with the slave, the lock would be set, the "owner" of the lock would have control of the bus, then when done release. If there were multiple, independent yet shared (by some slave devices) SPI buses, or maybe an SPI bus and another bus (I2C), then I'd have more than one of these bus control objects. (As you point out, this could be done by adding support for multiple soft-locks protected behing a single hard-lock).

I'm also open to comments on this shared bus design. If there are any suggestions I'll start a new thread.

Thanks for pointing this out, Phil. It's prompted me to think further on the subject.