Volatile Variable Question

[seulater]

I want to make sure I am 100% clear on volatile variables when it comes to using them in an OS environment. Below I will give and example of 2 tasks using the same variable, I would like to know if this global variable "needs" to be volatile or not.

// global variable ticker
BYTE ticker = 0;

void Task1(void)
{

iprintf(Ticker is now %u\r\n",ticker);

if(++ticker >= 100)
{
ticker =0;
}

}
void Task2(void)
{
if(--ticker == 0)
{
ticker = 10;
}

iprintf(Ticker is now %u\r\n",ticker);
}

[Ridgeglider]

Seulater: I think you may be confusing two concepts. When you qualify an object as volatile you simply instruct the compiler to never assume the value of the object. For example, if a function accesses a non-volatile object, does some stuff and then re-accesses the same object later, the compiler might read the value once, and store it in a register for use the second time in an effort to speed up access. From the compiler's perspective, it assumes that since the object is not being modified and subject to change, temporary storage in a register's a reasonable optimization. However if the object can be changed by another process (like an ISR or another task), that assumption is wrong. Using volatile just says don't assume the value of this object, go read it from the object's address EVERY time.

Your example has two tasks that both write to the same variable. I try to avoid these situations. Assuming the object is atomic ie 32 bits, I let many tasks read the variable, but I try to only let one task write to it. If two tasks must absolutely write to a variable, or if the variable is non-atomic, (ie more than 32 bits, and therfore requiring more than one write cycle to update), I set up an OSCriticalSection to protect access. Usually there is some additional code near to the object being protected (eg configuration of other related variables or processes) that also needs protection: you are updating an entry in an array, but you also need to adjust the pointer to the next element. Think of the object not as a variable, but as a resource (like a print driver) that multiple tasks need write-access to. The OSCriticalSection ensures that a given task is really done before relinquishing access. Your example where two tasks are writing to ticker looks like it will produce very unpredictable results. Consider haing Task2 send a semaphore to Task1 indicating that the variabe should be changed. That way the code is much more deterministic. If necessary Task1 can send an Ack Semaphore back saying it's done.

My rule of thumb is that if multiple tasks are reading an object that might be modified by one of them, then make the obect volatile. Then every access will make no assumptions. Worst case: your code is imperceptibly slower, but you will never get the wrong answer. You might if the object is not qualified by volatile.