FreeRTOS_select() timeout with uxTaskGetSystemState()

Libraries
1

I am running a simple client and server task.

The client task is blocked on FreeRTOS_select() (or should be, since I set xBlockTimeTicks to portMAX_DELAY).

The server calls uxTaskGetSystemState().

When the server then blocks and the client begins to run, FreeRTOS_select() immediately returns 0, implying a timeout (according to the API documentation).

The documentation says that uxTaskGetSystemState() suspends the scheduler for an extended period. Is this the cause of FreeRTOS_socket() timing out despite the argument to block indefinitely?

If I remove the call to uxTaskGetSystemState(), the client behaves as expected (i.e., FreeRTOS_select() blocks until an event on a socket in the socket set).

I can convince myself that this makes sense, but I couldn’t find any explicit documentation, so I wanted some more experienced confirmation before I stopped debugging and moved on to other things.

I’m running kernel V10.1.1 and TCP V2.0.11.

Mike

2

uxTaskGetSystemState() should not change the state of anything and if you have an infinite block time keeping the scheduler suspended for a while should not make any difference:
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/master/tasks.c#L2522 Can you step through the code to see why it is unblocking a task. It may be more likely that there is a memory error or overflow and calling uxTaskGetSystemState() is corrupting something.

3

Thanks, Richard. With your encouragement, I chased down the problem. It was much simpler than a corruption: FreeRTOS_select() was being called in two places, and I was only adjusting the timeout to portMAX_DELAY in one of them. uxTaskGetSystemState() (and processing the returned state information) was taking just long enough for the second one (with the default timeout of 0.5s) to timeout.