FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [August 2012 Threads] Why isn't xTxLock in xQueueHandle volatilePosted by Justin on August 1, 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?
RE: Why isn't xTxLock in xQueueHandle volatilePosted by Justin on August 1, 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.
RE: Why isn't xTxLock in xQueueHandle volatilePosted by Dave on August 2, 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?
RE: Why isn't xTxLock in xQueueHandle volatilePosted by Richard on August 2, 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.
RE: Why isn't xTxLock in xQueueHandle volatilePosted by Richard on August 2, 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.
RE: Why isn't xTxLock in xQueueHandle volatilePosted by Justin on August 3, 2012 Thanks for your analysis.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|