rtel wrote on Tuesday, September 15, 2015:
The mcro XSemaphoreTake always sets xJustPeeking pdFALSE. Therefore the comment under XSemaphoreTake() is false, period, unless the definition of poll says to “take it anyway and return the status”. This is not what Windows does in a similar situation and removes the ability to poll (peek) the semaphore status without affecting the flag.
Now the question becomes linguistic
As you say, I think this is a linguistic thing. Let me explain how it is intended to work, then if you don’t think this is how it is working, please let me know and I will investigate.
If you peek a queue then you return the first item in the queue (assuming there is data in the queue) without modifying the queue. That is, the item remains in the queue. Remember semaphores are macros that use the queues, so like many other queue API functions, you can also call xQueuePeek() on a semaphore.
If you read from a queue then you actually remove the item from the queue. If you take a semaphore, then you make the semaphore unavailable to any other task. When you read a queue, or take a semaphore, you can specify a block time, and the block time can be 0. If the call specifies a non-zero block time then it is a blocking call - if the queue is empty, or the semaphore is not available, the calling task will wait in the Blocked state until it either times out or data becomes available. If the call specifies a zero block time then it is a pollilng call because the function will return immediately to the calling task. If you make a polling (zero block time) call to take a semaphore, and the semaphore is available, then you will obtain the semaphore - as you called a function that is intended to take the semaphore you just specified a block time of 0.
I think this terminology is in common use. For example, if I am waiting for a bit to become set in a register then I can poll the register by sitting in a loop continuously reading the register, until the bit is set - or I can make a blocking call in which case I wait for an interrupt to tell me the bit is set. If I poll a semaphore, then I can sit in a loop continuously trying to take the semaphore with a zero block time, until the semaphore becomes available.
The behavior of a semaphore in this example, and a queue are different, yet the semaphore is a one unit queue. Using xSemaphoreTake with a duration of 0 does affect the semaphore, and to me, it should not.
I don’t understand this. If you read a queue with a block time of zero, and there is data in the queue, then you will modify the queue too.
I will maintain that xSemaphoreTake with a time of zero should not affect the semaphore,
Is it not legitimate for somebody to want to take a semaphore with a block time of 0? In your scheme, how would that work?
It was intended to work differently, and does not.
As I said, I think this is purely a linguistic issue. You want to be using the xQueuePeek() function, not the xSemaphoreTake() function.