views:

101

answers:

5

So this is a very particular question:

I use an embedded system with a single CPU core.

I have one main thread and an interrupt. They share a 32-bit float. The interrupt writes the float, and the main thread reads it. Reads and writes are not synchronized.

The processor documentation states that the 32-bit read is a one-cycle operation.

Am I right in my assessment, that there is no risk that the main thread will read a corrupted value? Or are there other factors?

+3  A: 

As long as both reads and writes are atomic operations, it should be fine. How long a read or write takes is immaterial, though it seems likely they are atomic if they are 1 cycle.

Chris Dodd
Would it matter if the write is two cycles?
kotlinski
Both the read and the write would have to be atomic for this to work. If so, you're good to go.If there's a problem with that, you could find some memory operation where read and write are both atomic, like a byte. Then you could use that as a semaphore to restrict read/write access to the float.
Bob Murphy
Also, is it always true that one-cycle operations are atomic on single cores? The documentation only explicitly says that test_and_set is atomic.
kotlinski
@kotlinski: A one cycle operation is automatically atomic (e.g. it either entirely succeeds or entirely fails, there's no half-done state). Whether a two cycle operation is atomic will depend on your CPU.
Bob Murphy
You need to use atomic operations. If you're not positive the two-cycle write is atomic, you need to use an explicitly atomic operation to control a semaphore.
Bob Murphy
Does it really matter if the write takes two cycles? I am relatively sure it would take more than two cycles to return from the interrupt to the main thread.
kotlinski
A: 

I think you are fine as long as the interrupt routine does not read the value, and then use the value to compute a new value to write.

Does the documentation also state that a write takes one cycle? If not, then you need protection.

aaaa bbbb
A: 

Should be safe - if you suspect it's not, you could disable interrupts before reading the value, then enable after the read. But I'm pretty sure you are fine -

Jeff
A: 

Atomic reads/writes might not be the only consideration in order to make operations thread-safe. I think the answer would depend on the OS memory model as well. You need to make sure that a read in your main thread will get the latest value written by the interrupt.

Kim Major
Since it's only running on a single core, the CPU memory won't come into effect - CPU memory models matter most when different cores may see reads/writes in a different order than they were issued by the other CPU.
Michael
Couldn't it be the case that the compiler re-order code which could cause an issue on a single core machine as well?
Kim Major
When you said memory model I presumed you meant CPU memory model. Compiler re-ordering will still be a factor (most likely need volatile).
Michael
Ok. I edited the answer to make that clear.
Kim Major
+1  A: 

Sounds to me like you're safe. If the read is done at once, no one can write to only half of the bytes. Having that said, you do need to make sure the value is always being really read by your thread, instead of being optimized away by the compiler. This might happen if the compiler thinks no one could possible change the variable from the outside. Declaring it as volatile should do the trick (if applicable at all - I'm not familiar with your code).

eran