anonymous wrote on Wednesday, August 01, 2012:
I am reading queue.c from FreeRTOS version 7.1.1
I am noticing that xTxLock is accessed both from ISR and task code (same for xRxLock).
Wouldn’t it need to be declared volatile to ensure that neither the task called function does not cache the value in a register?
anonymous wrote on Wednesday, August 01, 2012:
Forgot to add that is is similar to this post http://www.freertos.org/FreeRTOS_Support_Forum_Archive/September_2006/freertos_Queues_and_compiler_optimization_GCC_1582595.html
But there did not appear to be a definitive answer.
davedoors wrote on Thursday, August 02, 2012:
Interesting question. I think volatile is often used to often in FreeRTOS and could be speeded up with less but I’m not sure in this case.
Looking at xTxLock,
It is used in xQueueGenericSendFromISR() where the function tests and sets a value in a structure passed in as a pointer. The optimizer cannot determine how the value is used so should not optimize the code away.
It is used in prvUnlockQueue() where the same logic applies but in this case the function is quite short so the optimizer could potentially try and inline it.
It is used in the macro prvLockQueue() which is used in xQueueGenericSend() and xQueueGenericReceive() which are also the functions that call prvUnlockQueue(), so if prvUnlockQueue() is inlined the compiler can see xTxLock is being used but might not see why as it is never tested.
Comments Richard?
rtel wrote on Thursday, August 02, 2012:
There might be something in this, as the compiler does not know the value is being tested in an interrupt, I’m looking into it.
Regards.
rtel wrote on Thursday, August 02, 2012:
Having looked at this, my conclusion is that the xTxLock and xRxLock variables should probably be made volatile, for absolute certainty, although it is probably not necessary.
My reasoning is that the locking and unlocking is not performed in the same function. While the locking is inline, the unlocking is performed by a separate function (prvUnlockQueue()), therefore the compiler will probably not see an increment then decrement of the lock count without the incremented value ever being used unless prvUnlockQueue() was itself inlined - which is unlikely - or cross function optimisation was used.
However, as the word “probably” appears in that sentence, it makes sense to make them volatile. Thanks for pointing this out.
Interestingly the uxMessagesWaiting value is volatile, but probably does not need to be, as it is incremented and decremented in completely different functions, with completely different execution patterns. Dare I take that out though :o)
Regards.