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)