While test and set is not used much, the compare and swap that replaces it is based on the same idea, it just works on a full word (or doubleword) instead of testing a single bit. I think that the compare and swap would be a better model to follow than test and set. See: publibz.boulder.ibm.com/epubs/pdf/dz9zr006.pdf for the difference details.
No disagreement here, but I've written an awful lot of cross-memory code and never needed either one.· If I never write another AXRES, AXSET, or AXEXT, the world will be a more peaceful place for me.
I think I've written at least one piece of code where a lock was useful. Although most wouldn't use a lock, there is that very small percentage of solutions for which locks are indispensable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
Yes I've used locks. My project that I've talked about at the end of THIS Thread by Beau Schwabe uses three locks if I remember right. This project currently has five cogs waiting to receive command packets from the serial port, move the attached servos as commanded, and report the results. One lock each is used to protect the serial transmit and receive buffers. This keeps packets intact, and the separate locks are needed to keep the idle cogs waiting for a command from blocking any finished cogs from sending a response. The last lock is used to form eight software locks to insure that servo's and their data structures are only used by one cog at a time.
I certainly could have re-coded this as five parallel state machines running on a single cog with locking done totally in software, that would've taken a lot longer to code and test for no benefit in this application.
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
I just used locks for the first time. Was getting strange results from my display object. Turned out to be multiple cogs altering the display at the same time.
Eight Talking Cogs in the Propeller Object Exchange taught me how to use locks. My Fountain program (http://www.parallax.com/tabid/722/Default.aspx) uses two locks to permit multiple cogs to output messages to two different devices. I am happy with eight locks. I would miss them if locks were not in the next Propeller. Glad to know you plan to keep locks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dennis B. Page, Page Radio Company
can we have 32 of them just to round out a long? i can definitely deal with 8. there are ways around getting more through hardware/software combination but they are so convenient and quick this way. not a must but if not difficult would be nice in the rare situation more then 8 are needed.
mctrivia said...
can we have 32 of them just to round out a long? i can definitely deal with 8. there are ways around getting more through hardware/software combination but they are so convenient and quick this way. not a must but if not difficult would be nice in the rare situation more then 8 are needed.
I know that this issue has been settled but just for the record Eric recommends using locks in his HDMF driver
Eric said...
13. Hey what about game sound effects?The next version of the HDMF driver will include a “Passthrough” call which lets you call the sound driver via the HDMF driver for sound effects playback. It’s pretty trivial to add yourself if you need it now; just be careful to use a lock(i.e. LOCSET(), LOCKCLR()) around both the newPlaySoundFM() call and the one you add; they’ll be getting called from different cogs so you’ll need to use the locks to keep the calls from colliding.
I've used locks a couple of times as well. Needed them when multiple cogs were playing around with the spin bytecode for DOL so that the object table didn't get wrecked [noparse]:)[/noparse]
I just saw this post and I am glad that you are keeping the LOCKS in. I use them a lot for their intended purpose ... controlling access to shared resources. For example I rewrote the I2C object to use locks because I use the same I2C object from several cogs to communicate with various external devices. I keep them from stepping on each other via the LOCKS. I do the same for other devices too, RF for example outputting telemetry and debug info from several cogs ( ... robot stuff).
Thanks for keeping them in, they are indispensable.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I certainly could have re-coded this as five parallel state machines running on a single cog with locking done totally in software, that would've taken a lot longer to code and test for no benefit in this application.
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dennis B. Page, Page Radio Company
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
I just saw this post and I am glad that you are keeping the LOCKS in. I use them a lot for their intended purpose ... controlling access to shared resources. For example I rewrote the I2C object to use locks because I use the same I2C object from several cogs to communicate with various external devices. I keep them from stepping on each other via the LOCKS. I do the same for other devices too, RF for example outputting telemetry and debug info from several cogs ( ... robot stuff).
Thanks for keeping them in, they are indispensable.
Chip, don't you have 60 of 64 instructions in use now ?
Scott