Accessing a shared volatile variable

> If you need atomic access you need to enforce that yourself.

Half true. The particular core/MCU must implement atomic operations (i.e. machine instructions), and you probably need to resort to assembler to enforce such an operation. The Cortex M has macros for this purpose (in the CMSIS headers, though ...)

Hi,

To me seems the o/p has some problems with semaphores - best to do a Google search with the keywords "dijkstra semaphores".

Also, the code, as posted is some kind of deadly embrace - (not working) See this:

Vindhyachal Takniki said:

main_read = 1; data_read = vol_var; main_read = 0;

If main_read is 0, then there is no chance to go through other code lines.

Take care the semaphore is set in one part of the code and cleared in another part. There are a second backward semaphore, which should not be there.

Also, this may be related to producer(interrupt routine) - consumer(main-code) operations which depends on time/execution time.

f. m. said:

resort to assembler to enforce such an operation.

Which is "doing it yourself"

Atomic is outside of the scope of C and C++

Robert

That's correct, semaphores and the like are typical OS metaphers.

However, if I remember correctly, the latest CMSIS version(s) come with an RTOS API. (I never checked what it actually implements....)

I said you are in some *kind* of non-working code: while the vol_var may change a lot, their copy may be not upadated properly, (why do you need a copy? what will you do if vol_var_copy never gets updated?, due to interrupt timing) so you may have more trouble working with bad values. The interrupt may occur any time, so it still exists the possibility of bad working, supposing there is some other code in your project. Try to vary the interrupt time and see if still working. Don't base your design on a sigle case/value.
Otherwise, to protect values , you may try to use Exclusives. This is accomplished by using .asm instructions LDREX and STREX. This makes it possible to read a value from memory (byte, half, word, or bit), modify it, and then write it back; if another task or an
ISR has written it between the load and store, the store will not happen and you will be told that via a register. So, you use a spin-lock model with no extra test-and-set location. Exclusives can be used for FIFOs (e.g. from ISR to main/tasks or main/tasks to ISRs) as non-locking and non-blocking models, as well as for many other shared resource.
In CMSIS package you can find out some macros to play with that, as nothed by other posters here.
As for other micros, 8- or 16-bits, the "atomic" problem still remain unsolved, may depend on micro, what I have used up to now do not have that.

Vindhyachal Takniki said:

if(1 == main_interrupted)
{
data_read = vol_var_copy;
main_interrupted = 0;
}

Vindhyachal Takniki said:

void isr(void)
{
if(0 == main_read)
{
vol_var = value;
}
else
{
main_interrupted = 1;
vol_var_copy = value;
}
}

That, in general, cannot work. You cannot be sure of the order in which those two writes take place. In the worst case a write can be interrupted part way through.

Writing a variable from interrupt and main code can only be done if you protect the writes so only a single process can do so at once and you ensure that reads are likewise not interrupted¹. Yes, that means you will need to disable that interrupt.

What you want is a non-blocking algorithm². For that only a single process writes to a variable, the other reads. There is such an algorithm for FIFOs and that may be what you need. However, for things like timers where all you are interested in is the latest value the usual approach is multiple reads. If the value changes between reads you know there was an interrupt and you try again. Simple and robust.

Robert

1 - It is possible in some cases to make multiple writers work w/o blocking but the amount of effort required to prove that there is no problem and the high risks of getting it wrong usually makes other approaches superior. I'm not sure I've ever done it and really it's asking for trouble unnecessarily

2 - I suggest spending a little time looking up non-blocking algorithms. It'll be worth your while understanding what they are doing and will provide references you are going to need later.