Memory locking?

Philldapill

I've got an ADC running all the time in a single cog. What it does is, it gathers 100 samples, then averages them and stores the average in a variable. The ADC is actually an object, so it has a method of retrieving the average variable. The main cog accesses this variable through ADC.getAverage. It is totally unsynched to the other cog.

I was wondering if there could ever be a conflict where the ADC cog is writing the value into the variable while the main cog is trying to retrieve it. Could this be a problem? Oh, this is all in spin, btw.

Ale

Remember that the HUB read and write from different cogs occur always at different times through the HUB sync mechanism, they are sort of atomic pending an access from a higher priority COG (with lower id)... What may happen is that you read a not-yet-updated value, but that has nothing to do with how the prop works.

Timmoore

So the only conflict is the average variable? I believe that spin uses rdlong and wrlong to access longs. So if the average is 1 long then, 1 cog is doing a wrlong and another cog is doing a rdlong and the hub syncs them. So as long as 1 cog is writing and 1 cog is reading, you shouldn't have a problem. If the average is more than 1 long or byte or word as accessed as such then you may have a problem. I have found that you can assume writing and reading to a single byte/word/long is ok, but you will have to handle syncing multiple variables such as arrays or if you write from 2 cogs, etc.

hippy

I'm also of the opinion you won't have a problem because only one Spin program can ever access memory at a time ( access is always via the hub spinning ) the worse thing that will happen is you'll read the shared variable just before it is updated, but it will still be valid and correct data.

That would not be the case if the variable were being written to not as a single word or long, but written a byte at a time. In that case a read could get a value where one byte had changed and the other three had not which would give a wrong result.

Likewise you could have problems with side-effects ...

average := ( ++average + latest ) / total ' meaningless code, just an example

Here the ++average will alter the shared value which could be read before the final value for average was calculated and written out.

All easy enough to avoid, so as long as none of these occur you'll be okay.

Ken Peterson

If changing the variable involves only one hub access (byte, word, long) then it's atomic, meaning it cannot be interleaved by another cog. If access to your variable involved more than one hub access (>long, or an array as mentioned above), then it is no longer atomic and can be interleaved with another cog access. In this case you should incorporate a lock in your program to prevent a race condition.

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

Philldapill

Great! I had a feeling it should work ok due to that exact reason about one cog access to the hub at a time. I haven't ran into a problem, but if this is going to be some permanent code, I just wanted to make sure. Thanks guys!