Hi, The Question Is it safe to have the software timer call vTaskSuspendAll() and xTaskResumeAll()? For a variable which has a reader in another task. The problem I have a Stack which needs to increment a variable every 10ms. I use a software timer to increment this variable, in the baremetal case this would be done from an ISR. What I have done instead is use a software timer to increment this variable but the variable is read from another task. So I decided to call vTaskSuspendAll() and xTaskResumeAll() before incrementing the variable. Is there any potential problems to doing this?

vTaskSuspendAll()/vTaskResumeAll() should be ok there, in fact, in another question, it was pointed out that sometimes timer callbacks are called inside such a pair. Personally, I think that is a bit overkill, for something as short as this, a critical secion (taskENTERCRITICAL/taskEXITCRITICAL) makes more sense. as this is much quicker, and the operation is quick enough that it is resonable to disable the interrupts for that short of a period. There also is the possibility that you don’t need any forms of protection for this. If you only have one writter, and all reads and writes to this value are atomic (single instruction), then you don’t need any protection, as all reads will get a valid value from before or after the write.

HI Richard, Thanks for the quick reply. Can you elaborate more on your comment below. How can you be 100% certain that it’s atomic? Is it not possible for a context switch to occur at any point since the code base allows preemption?

There also is the possibility that you don’t need any forms of protection for this. If you only have one writter, and all reads and writes to this value are atomic (single instruction), then you don’t need any protection, as all reads will get a valid value from before or after the write.

The fundamental issue with sharing variables between tasks is that you need to be sure that every access sees a ‘valid’ value. If all the operations are effictively atomic, this isn’t an issue, so adding protection isn’t needed. As an example, lets look at a case where it would be needed. Let us assume we have a counter counting in minures and seconds as two distinct variables. Let us say that the counter is currently at 1 minute and 59 seconds, and one task is going to read this value and another increment it. The incrementing task will first change the seconds from 59 adding 1 to get 60, see that it is time to roll over and set it to 00 and then go and increment the minutes from 1 to 2. That says that the counter existed with sequential values of 1:59 1:00 2:00 So if something of a higher priority came in between setting to 1:00 and 2:00 it would see the wrong value. Another issue is a lower priority reader might first grab the seconds, and then the minutes, and if this was interrupted by the increment, it might get the value 2:59, which again is wrong. With this sort of non-atomic read/update, you need to guard the accesses so that you can’t interrupt a read or update to get an inconistant value. IF on the other hand, this value was stored in something that was read or written in a single atomic cycle, then these issues couldn’t happen, as the increment couldn’t break into the ‘middle’ of the read, and if the update is atomic then the 1:00 value was never written into the variable, so nothing could have gotten that value. SIngle writter is normally important, as writers often need to read the value, do something with it and then write back the new value. And from a writer prospective this needs to be atomic too. If there is only one writer, this isn’t an issue, but if multiple tasks might update the value, they normally need to guard things such that nobody else can modify the value between when they read the old value and wrote the new value. If the value being read and written is accessed/changed with a single instruction, then by the design of the hardware, this will happen atomically. You can’t get part of the result, then go off and do another task, and then come back and finish the rest of the instruction’s access. The only way to be absolutely 100% positive of this, is to inspect the assembly code generated, but generally, access to ‘int’ variables will be atomic on virtually all processors.

Hi Richard, Thanks for the full explanation, your dedication to this forum is greatly appericated. The scenerio described above is exactly what I was thinking.