There is nothing the lock accomplishes that can't also be accomplished by an atomically written numeric flag, but the lock does save a byte of RAM and a few runtime instructions since you don't have to write a claim value and check to make sure it stayed written before using the resource.
IIRC you can't get guaranteed performance without locks - without them all performance is probabalistic (which without randomization translates to sporadic lock-up conditions, absolutely fatal for OSes). But I may be misremembering.
rockiki: Kye can have multiple files open at a time. Locks are his protection from higher level coding errors when multiple versions of his code are running. BTW did you do the later mb-rawb-spi26 code that lonesock released?
My name is "rokicki".
fsrw has supported multiple open files too, of course. That's a completely orthogonal concept
from locks, which are low-level primitives that permit proper concurrent access in a
multithreaded environment. Building in locks at a low API level do not guarantee a proper
architectural solution to concurrent access; frequently they just give the illusion of having done
so, in the end doing more harm than good.
I do not know what you mean when you ask if I "did" the "later mb-rawb-spi26 code" that
lonesock released. Can you be more precise, please?
Sorry rokicki. I just typed your name without checking your post.
I used your (Thomas Rokicki and Jonathan Dummer) fsrw2.6 driver in ZiCog and it works brilliantly. I then converted to use the later drivers mb_rawb_spi26 (Jonathan Dummer aka lonesock) which I believe were faster. I have been working on an OS based on Kye's SD-MMC_FATEngine v2.0. I have a good look at the pasm drivers of both Kyes and lonesocks and they are quite similar in that they now both use the counters. My question was, did you and lonesock do the mb_rawb_spi26 or was it just lonesock?
Back to topic... FWIW I have not used locks as I have not had the need to do so.
MagIO2: Do you agree my lock code works? I cannot see any flaws. If all agree, I will post it to the obex as an alternative example.
Boy now you guys have gone an done it. I am no long sure what seems to be working is safe.
I have 4 cogs (all in PASM) writing to 4 consecutive 128 byte Circular Queues incorporated into a Master Queue monitored by a 5th COG (in PASM) and that 5th COG reads a single HUB Long which contains a byte pointer for each of the 4 sub-circular queues.
I read the pointer LONG from the Hub and compare it to the last read and I can tell if any of the 4 other cogs had added to any of their queues and if so I use the individual bytes from that one LONG HUB read to give me the address of the last data in any given sub-circular queues.
Again, this seems to work and using the single LONG HUB read to spot any of the 4 queues with new data seems to be very efficient and so far I have not required a lock. I think my saving grace is I made sure the COG reading and processing the Master Queue operation can process faster than the 4 COGS writing the data so I don't even bother to check for queue full or overflow.
Rather than having locks which are an all or nothing affair, how about a numerical value associated with how much a process needs to access a shared resource. As the desire for access increases, so does its numerical value. For a biological example, think of your desire for food after a meal, 5 hours after a meal and 2 days after a meal. Actually, many biological desires work like that. Food. Sleep. Bladder. Bowel. Reproduction.
If we are in control of the rules of lock usage in our own programs, could it be possible to use multiple lock bits to achieve this? Designate a single process to the first couple locks to signal importance based upon a rule set? Say if a process locks something, and utilizes 2 locks to do it, it would be higher priority than something that wants to flag one lock. If in fact something with a higher priority needs a resource with only one lock, it could save the state of the machine to a set of pre-defined variables (external sram, hub ram, whatever you have the space for), set the lock set accordingly, then perform the needed function. when done, just restore the state of the program, set the locks to the lowered priority state, and continue on with the orignial processing thread.
I have no examples where this would be useful, but wouldn't this be at least possible? In the spirit of what mindrobots said:
very handy when you start working at an OS level and look to creating multiple code threads
I could see where this would take the place of interrupts, and be quite effective in prioritizing more complex programming. But hey... even I am prone to musing on the impossible and unuseful.
Wurlitzer, your method is OK as long as the 4 cogs only write a single byte within the shared long. That is, if they use WRBYTE it's OK. However, if they do a RDLONG, modify their byte, and a WRLONG back to the shared long there could be a problem.
Comments
IIRC you can't get guaranteed performance without locks - without them all performance is probabalistic (which without randomization translates to sporadic lock-up conditions, absolutely fatal for OSes). But I may be misremembering.
I know ... just was thinking that maybe these distinguished for a reason which might be valid here as well ;o)
My name is "rokicki".
fsrw has supported multiple open files too, of course. That's a completely orthogonal concept
from locks, which are low-level primitives that permit proper concurrent access in a
multithreaded environment. Building in locks at a low API level do not guarantee a proper
architectural solution to concurrent access; frequently they just give the illusion of having done
so, in the end doing more harm than good.
I do not know what you mean when you ask if I "did" the "later mb-rawb-spi26 code" that
lonesock released. Can you be more precise, please?
-tom
I used your (Thomas Rokicki and Jonathan Dummer) fsrw2.6 driver in ZiCog and it works brilliantly. I then converted to use the later drivers mb_rawb_spi26 (Jonathan Dummer aka lonesock) which I believe were faster. I have been working on an OS based on Kye's SD-MMC_FATEngine v2.0. I have a good look at the pasm drivers of both Kyes and lonesocks and they are quite similar in that they now both use the counters. My question was, did you and lonesock do the mb_rawb_spi26 or was it just lonesock?
Back to topic... FWIW I have not used locks as I have not had the need to do so.
MagIO2: Do you agree my lock code works? I cannot see any flaws. If all agree, I will post it to the obex as an alternative example.
cog := cognew(....)+1
I have 4 cogs (all in PASM) writing to 4 consecutive 128 byte Circular Queues incorporated into a Master Queue monitored by a 5th COG (in PASM) and that 5th COG reads a single HUB Long which contains a byte pointer for each of the 4 sub-circular queues.
I read the pointer LONG from the Hub and compare it to the last read and I can tell if any of the 4 other cogs had added to any of their queues and if so I use the individual bytes from that one LONG HUB read to give me the address of the last data in any given sub-circular queues.
Again, this seems to work and using the single LONG HUB read to spot any of the 4 queues with new data seems to be very efficient and so far I have not required a lock. I think my saving grace is I made sure the COG reading and processing the Master Queue operation can process faster than the 4 COGS writing the data so I don't even bother to check for queue full or overflow.
I have no examples where this would be useful, but wouldn't this be at least possible? In the spirit of what mindrobots said:
I could see where this would take the place of interrupts, and be quite effective in prioritizing more complex programming. But hey... even I am prone to musing on the impossible and unuseful.