PDA

View Full Version : Does anyone use LOCKs???



cgracey
01-23-2009, 03:42 PM
Do any of you use the LOCK mechanisms for any purpose? While they are theoretically useful, I've never used them in any application and I've never seen anyone else use them. I'm just wondering if they would be missed in the next Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

william chan
01-23-2009, 03:50 PM
I also never used locks.
I just make sure only 1 cog writes to any data, the other cogs only read.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my (http://www.fd.com.my)
www.mercedes.com.my (http://www.mercedes.com.my)

mirror
01-23-2009, 04:07 PM
Yeah, I seem to remeber seeing them in some multi-cog-use FIFO thing.

Whether or not they were actually required ... well I don't know.

Personally, I've never used the locks, if they no longer existed I wouldn't miss them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Ale
01-23-2009, 04:09 PM
Chip,

I have an application that uses 2 propellers. One of them takes some samples from an ADC and calculates FFT and displays the results. For that I need 32k RAM (all the HUB) and some extra RAM that has to be shared. I though using locks to signal a few states. I'll probably go that route. This is not a commercial application, just a custom machine for my thesis. As soon as I publish it I'll post it here. It uses the uniqueness of the propeller. Well, what I wanted to say was: if comm channels existed between COGS in addition to shared memory (but not as only comm medium) some things could be done easily, may be more in parallel (i.e. no waiting for a variable to change and wasting power) without putting so much pressure on HUB memory and variables that point to shared HUB addresses.
Not to start another propeller vs. xmos thread but: Working a bit with the XMOS where shared memory is discouraged and everything should be done with channels, I started to appreciate more the benefits of shared memory. I though of new ways of using the parallelism the propeller brings to my application. May be a small channel. just a 1 or 2 longs buffer could open a very interesting applications. I have no idea how feasible that would be.

Bottom line: when I may use them in this particular place... I will hardly miss them. The channels otoh seem like a very useful addition, I if could choose.

Cluso99
01-23-2009, 04:20 PM
I have never used them, nor seen a requirement to do so. However, I use a mechanism to synchronise two cogs where I set a hub location by one cog and clear it with the other. This works efficiently and is foolproof (because you may not clear it until it has been set by the other, and visa versa).

I did extensive programs in the 70's & 80's using a minicomputer with similar concepts to the Propeller (hub and cog memory and simulated multiprocessors). Software locks were used.

So, to answer your question, I will not miss them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index (http://forums.parallax.com/showthread.php?p=778427)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)

Baggers
01-23-2009, 04:26 PM
I've never used LOCKs either :D I'd go with the idea of if you have another use for the instruction space, lose them and use it :D besides, I'm sure it'll be something mega important since you're asking in the first place :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

cgracey
01-23-2009, 04:32 PM
Thanks for your input, so far,·Everyone.

Baggers said...
I've never used LOCKs either :D I'd go with the idea of if you have another use for the instruction space, lose them and use it :D besides, I'm sure it'll be something mega important since you're asking in the first place :) It's just about keeping things tidy.·It's good to reduce unnecessary silicon, instructions, documentation, mindshare, etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Baggers
01-23-2009, 04:54 PM
very true, cluttered desk and all that lol

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Timothy D. Swieter
01-23-2009, 06:58 PM
I haven't had a situation where I have considered the locks yet. Of course, I don't think most of the stuff I do is intense enough to rank my opinion among others here. Either way, I usually prefer software handling of which cog has rights to which resources.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Rayman
01-23-2009, 09:00 PM
I've never had the need for them in anything I've done so far.

heater
01-23-2009, 09:08 PM
I almost asked that question here the other day, just out of curiosity.

Given that I only have one serious Prop project, PropAltair, and it does not need locks the answer is no.

Then I started thinking......

Back in the day when I used to program rack fulls of 16 bit CPUs with shared memory cards the only lock mechanism we had on those custom CPUs was a LOCK EXCHANGE instruction. That is: the read and the write of an exchange operation between CPU register and RAM could not be interleaved with any other bus activity from other processors. Using that to test and set a semaphore in shared RAM any amount of RAM or other resource on the bus could be "protected".

Things got interesting when I was supplied with prototype CPUs without the lock and no one told me....

Looking at the Intel x86 architecture we see the same lock idea but extended slightly so the lock works with more instructions, namely:
* Bit test and change: BTS, BTR, BTC.
* Exchange: XCHG.
* Two-operand arithmetic and logical: ADD, ADC, SUB, SBB, AND, OR, XOR.
* One-operand arithmetic and logical: INC, DEC, NOT, and NEG.

I have a felling people only ever use the "LOCK" prefix with XCHG on x86 anyway.

Conclusion: Looks like one could throw away the Props locks and all that checking out business and replace it with a LOCK EXCHAGE hubop, say LXLONG, LXWORD, or LXBYTE or all of them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

shanghai_fool
01-23-2009, 10:41 PM
I am only beginning with the Propeller and have been involved in getting various devices and sensors working independantly. I anticipate using locks as 1 bit semaphores in the main program rather than using bytes or longs just to test for status of various states. Since they are available to both spin or pasm, it seems to be the most logical method of communications between routines. I still have more research to do though.

Kye
01-23-2009, 10:55 PM
Heh, I actually tried to use locks once. But when I figured out it was impossible to read them, only write them and get the previous state, I decided that they were completely useless. Since I would need to have about 4 to 5 asm instructions to just use them. Also, I dislike how you have to keep count on which cog is using them anyway.

Having the locks also makes you want to use coginit istead of cognew, which is a bad idea anyway. Beacuse as I said you need to keep count of what is using them.

Now, if you could like literary assign memory locations to be read only or write only for certain cogs that would be interesting.

But, yeah, I never use locks. Waste of an opticode if you ask me.

Whats easier to use instead of locks is simply making a byte that gets set to true ($FF)·or false ($00)·when you need to synchronize stuff. Or better yet making everything FIFO buffered so you can transfer lots of data predictably.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mark Swann
01-24-2009, 12:02 AM
I believe I recall seeing some objects in the OBEX that use LOCKs

Mike Green
01-24-2009, 12:03 AM
Although LOCKs are rarely needed in practical programming, an indivisible TEST_and_SET operation is absolutely necessary and can be done much more simply if you can do a read/write hub memory cycle. It only requires that WRxxxx optionally set its flag bits (Z at least) based on the content of the memory location addressed, then sets the location to the destination value supplied, all on one exclusive hub access.

You need the TEST_and_SET because it's always possible (but unlikely) that another cog can modify your flag location between your TEST and MOV if you try to implement a lock that way. The reason we've needed them rarely is that most everything we do with multiple cogs involves the special case of the single producer / single consumer where only one cog modifies (fills) the structure, the other cog just accesses (empties) it and this special case does not require a semaphore.

heater
01-24-2009, 12:19 AM
Mike, that's ingenious. A kind of locked exchange but with result in the flags. Saves having to find a new opcode. Great.

If only there were a way to include a "wait" on such a semaphore so that a COG waiting on access to some data would go low power.

Sounds like Chip has got a cunning and devious plan up his sleeve and would like to make space for it by removing the locks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mpark
01-24-2009, 12:24 AM
I used a lock for the first time just last week in my wavetable music synthesizer. It came in very handy.

With multiple processors, some sort of locking mechanism is necessary, imho. Don't get rid of locks unless you can provide a functional equivalent.

Mark Swann
01-24-2009, 12:27 AM
I have found LOCKs usefull. I used Locks in a secret super-fast version of Float32 that I have been keeping hidden.

Phil Pilgrim (PhiPi)
01-24-2009, 12:55 AM
Yes, I use locks. As an example, I wrote a heap manager that allowed multi-cog access to one or several heaps. This would have been impossible without a hardware locking mechanism. I designed it with a single hardware master lock, with individual software locks for the various heaps. Here's how the master- and sub-locking was implemented:




PUB lock(heap) | lock_mask

'' Lock (suspend other operations on) the given heap (one-based heap index).

if running and heap > 0 and --heap < MAXHEAPS and heap_users[&#173;heap&#093;
'Legitimate call?
lock_mask := 1 << heap ' Yes: Create a mask from the heap number.
repeat ' Wait for heap to be unlocked...
repeat while lockset(master_lock) ' First, lock the main gate.
if not heap_lock & lock_mask ' Is heap locked?
quit ' No: Okay to exit loop and proceed.
lockclr(master_lock) ' Yes: Unlock the main gate and try again.
heap_lock |= lock_mask ' Heap was unlocked, so lock it with main gate still locked.
lockclr(master_lock) ' Now unlock the main gate.
return true ' Return success.
else
return false ' No: Return failure.

PUB unlock(heap) | lock_mask

'' Unlock heap (one-based heap index).

if running and heap > 0 and --heap < MAXHEAPS and heap_users[&#173;heap&#093;
'Legitimate call?
lock_mask := 1 << heap ' Yes: Create a mask from the heap number
repeat while lockset(master_lock) ' Lock the main gate.
heap_lock &= !lock_mask ' Unlock the heap.
lockclr(master_lock) ' Unlock the main gate.
return true ' Return success.
else
return false ' No: Return failure.




-Phil

lonesock
01-24-2009, 01:23 AM
I'm working on a project right now where I was planning on using LOCKs. Here's the scenario:

* cogA writes some data to a circular buffer, and updates a table with some info about the last data written, flagging it as new data
* cogB checks the table for new data and may or may not use some data, but either way flags in the table that it is not longer needed by cogB
* cogC checks the table for new data, then once enough data is collected dumps it to a SD card for storage and flags the data in the table as no longer needed by cogC
* cogA may only overwrite a section of the buffer if the data there is flagged as unnecessary by both cogs B & C

Also note that the situation is more complex than above, as multiple cogs get to play the roles of A,B,C.

Is there is a failsafe way to handle something like this without LOCKs?

thanks,
Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

cgracey
01-24-2009, 01:59 AM
It is not possible to use a location in hub RAM as a lock, since it would take TWO hub cycles to read,·(modify,)·then write any location. This would disrupt the single-cycle determinancy that now exists. This is why LOCKs were implemented as separate entities. Checking them out and·coordinating their # among cogs is a pain, but if you want to hard-code the LOCK # usage, there's no need to check out and return locks. Just write your code to use certain ones.

I think that in the current Propeller, due to hub RAM·limitations which dictate the type of applications written, LOCKs are not commonly needed. With 256K of RAM affording more system-level apps, though, there will likely be a more frequent need for them. So, I think I'll leave them in, as they are.

Oh, and about not having a mechanism to just read LOCKs... The conundrum is that if you read one, but don't request control (LOCKSET/LOCKCLR)·at the same time, your result is meaningless, since on the very next cycle, that LOCK's·status might change via another cog's LOCKSET/LOCKCLR activity, rendering your recent observation inaccurate. So, LOCKs are for participants, not for bystanders.

Does anyone think that 8 LOCKs are not enough? Would 16 be better?


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 1/23/2009 6:18:15 PM GMT

awesomeduck
01-24-2009, 02:13 AM
I agree with Mike Green, Test and Set instruction that is atomic is very useful. It enables you to continue processing in a loop then come back for another test instead of just hanging. While it doesn't seem that there are a lot of people saying they use the locks, I think removing hardware support for mutual exclusion on a multicore processor would be a mistake. Maybe the locks are not needed, but some hardware support for sharing resources seems very valuable, and if the next generation Prop has broader appeal in the market the need may be more apparent.

Mark Swann
01-24-2009, 02:18 AM
Chip,

Since LOCK ID check-out and check-in is not really required (I did not know that), can that function be eliminated to save op-code space? I would not mind defining my own LOCK IDs.

Mark

Phil Pilgrim (PhiPi)
01-24-2009, 02:21 AM
Using a hardware master lock/software sub lock scheme, as many locks as there are cogs would be adequate. Too, it would be rare in any app that every cog be managing a shared resource. Although the master-/sub-locking approach is a bit cumbersome, I'd probably still use it if more locks were available, since one can't know what the other cogs might require.

-Phil

cgracey
01-24-2009, 02:31 AM
Mark Swann said...
Chip,

Since LOCK ID check-out and check-in is not really required (I did not know that), can that function be eliminated to save op-code space? I would not mind defining my own LOCK IDs.

Mark

We've got plenty of opcode space, so that's not a problem. I think I will leave in the LOCK checkout/return mechansim, though, so that people can still use LOCKs like they use cogs via COGNEW. Otherwise, it would make integration of LOCK-using objects much more difficult.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Chuck Rice
01-24-2009, 03:25 AM
I have 4 propellers communicating serially. One is the communications board and the other three drive various robot functions. I use the locks on the communications propeller to ensure that traffic from one board does not clobber traffic from another when logging packets to an XBEE (serial connection to my laptop).

mctrivia
01-24-2009, 05:57 AM
i have not used locks myself yet but having an upper layer of cog ram with limited capabilities would be usful. say if you could only access it through special mov op codes. if you designated specific registers as the target or sorce you could make 4 bits the sorce and the remaining 14 the destination.

Erik Friesen
01-24-2009, 08:06 AM
I use locks for accessing the same I2C memory from different cogs. I suppose I could work without them but they are handy.

shanghai_fool
01-24-2009, 08:47 AM
Chip Gracey (Parallax) said...

Oh, and about not having a mechanism to just read LOCKs... The conundrum is that if you read one, but don't request control (LOCKSET/LOCKCLR)·at the same time, your result is meaningless, since on the very next cycle, that LOCK's·status might change via another cog's LOCKSET/LOCKCLR activity, rendering your recent observation inaccurate. So, LOCKs are for participants, not for bystanders.



I think I can still use locks in my scenario. I have a main routine that repeats very fast and monitors other cogs that operate asynchronoulsy. When a routine has new data, it sets a lock. The main routine then tests (lockclr) for new data but skips if there is none. As long as different routines can set/clear the lock, this should work.

i.e.
My main routine routine repeats every 1-2ms. New data can be from GPS (200ms), RC receiver (15ms), or ADC (5ms). I only need to do something when the data changes. So each routine sets a lock when it has new data and the main routine only processes when new data is available. It just seems easier than reading a hub memory location to test.

I am still working on the individual routines so this test will have to wait until next week.

Donald

Carl Hayes
01-24-2009, 09:15 AM
In a multiprocessing environment, or even in a merely multiprogramming environment, some kind of locking mechanism is essential.· However, really you need only a single hardware-implemented lock.· If one needs locks for multiple resources, it is easy to make one's own software locks·with a universal hardware·lock and a tiny bit of common storage.
·
One should implement two logical sorts of locks, though:· shared and exclusive.·

One obtains a shared·lock for the resource when one wishes to read it, and doesn't want anyone writing it·at the same time.· Many tasks (programs) can hold a shared lock simultaneously, and read the locked resource simultaneously.·

One obtains an exclusive lock when one intends to·change the resource and·doesn't want anyone else to try to read or write it·at the same time.

With a single exclusive hardware-implemented lock, one can make one's own locks for any number of resources, using one·shared-storage bit per lock if one needs only exclusive locking, perhaps a byte if one needs both kinds (you need a count of how many tasks are sharing).· This is really easy, and I leave the details as an intellectual exercise for the reader, pointing out only that one obtains the hardware lock (waiting if necessary) whenever one obtains a software lock, and immediately releases the hardware lock.· If one designs it right, one needn't obtain the hardware lock in order to free one's exclusive software locks.

A test-and-set instructiion, as in the IBM 360/370/390 mainframes and their successors, is an adequate substitute for locks in many cases, but requires considerably more expertise to use correctly.· The TS instruction fell into general disuse early in the history of OS/360, but was retained in the hardware for compatibility with older programs.· (Microsoft could learn a lot by a study of upward compatibility in the 360/370/390 series, by the way.· Through decades of rapid evolution in mainframes, IBM retained upward compatibility that was essentially complete for application programs.· By contrast, every time MS brings out a new release, old programs stop working.· That never happened with 360/370/390 applications.)

Anyway, I guess a TS instruction would be nice, but a hardware lock is better -- and only one hardware lock is sufficient.

The necessary instructions are :· (1)· Obtain the hardware lock (with an implied wait); (2) Free the hardware lock; and optionally (3)·Test to see if it's available.·The instruction for obtaining it may usefully have two variants:· wait if it's not available, or set a condition if it's not available.· If everyone's well behaved, the wait option is preferable in most cases, for no one will keep the hardware lock·longer than a few microseconds.

There are hints and kinks to using locks, most of which are cautions to observe when one needs to hold more than one lock at a time, in order to avoid the situation in which I have A and need also B,· and you have B and need also A.· If I wait for B and you wait for A, we both wait forever.· In the mainframe world one term of art for this is "deadly embrace".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net (mailto:nn5i@arrl.net)

Post Edited (Carl Hayes) : 1/24/2009 1:23:51 AM GMT

Chuck Rice
01-24-2009, 12:52 PM
Carl Hayes said...
A test-and-set instructiion, as in the IBM 360/370/390 mainframes and their successors, is an adequate substitute for locks in many cases, but requires considerably more expertise to use correctly. The TS instruction fell into general disuse early in the history of OS/360, but was retained in the hardware for compatibility with older programs. (Microsoft could learn a lot by a study of upward compatibility in the 360/370/390 series, by the way. Through decades of rapid evolution in mainframes, IBM retained upward compatibility that was essentially complete for application programs. By contrast, every time MS brings out a new release, old programs stop working. That never happened with 360/370/390 applications.)



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 (http://publibz.boulder.ibm.com/epubs/pdf/dz9zr006.pdf) for the difference details.

Carl Hayes
01-24-2009, 02:02 PM
Chuck Rice said...

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 (http://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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net (mailto:nn5i@arrl.net)

Ken Peterson
01-25-2009, 12:29 PM
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."

- Bjarne Stroustrup

Lawson
01-25-2009, 01:15 PM
Yes I've used locks. My project that I've talked about at the end of THIS (http://forums.parallax.com/showthread.php?p=582447) 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?

mctrivia
01-25-2009, 01:38 PM
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.

jmbertoncelli@USA
01-26-2009, 06:45 AM
I am using the lock(s) to manage the access to the shared memory variable(s) between the 8 cogs and it is working just fine.

dbpage
01-28-2009, 06:14 AM
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

cgracey
01-28-2009, 08:23 AM
Good to hear that you guys are getting the intended usage out of the LOCKs. They'll be staying, for sure, then.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

mctrivia
01-28-2009, 08:51 AM
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.

cgracey
01-28-2009, 08:56 AM
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.
It's easy to add them. We could.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

mctrivia
01-28-2009, 09:05 AM
thats great. when do you estimate the prop2 coming out? I want to build a 2048 chip supper computer. 300GIPs

Bob Lawrence (VE1RLL)
01-28-2009, 10:14 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

stevenmess2004
01-30-2009, 02:39 PM
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 :)

tellurian
02-06-2009, 09:27 AM
Chip,

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.

scotta
02-06-2009, 12:24 PM
"We've got plenty of opcode space"

Chip, don't you have 60 of 64 instructions in use now ?

Scott