As far as is understand is that when wiced_rtos_get_semaphore is called, it decrements the semaphore counter until the counter is zero. If the counter is zero, it will wait until wiced_rtos_set_semaphore is called and increment the counter.
The problem I'm seeing is when wiced_rtos_get_semaphore will timeout. It looks like the semaphore counter will still decrement on timeout, thus making next call to wiced_rtos_get_semaphore be blocked even though wiced_rtos_set_semaphore is called.
So in case of multiple wiced_rtos_get_semaphore timeouts, a multiple wiced_rtos_set_semaphore calls are needed to get the semaphore counter above zero.
Is this normal behaviour?
Am I therefore responsible to call wiced_rtos_set_semaphore if a wiced_rtos_get_semaphore timeout happens?
This does not seem like an expected behavior. Can you share the code that causes the issue? Also, what do you do after the time out has occurred in that task? When the get_semaphore times out, the task should unblock but you should not access the resource since it is not available (or not given).
Can you please let us know which device , SDK and IDE are you using in your application?
This thread was locked due to inactivity for a long time, you can continue the discussion on the topic by opening a new thread with reference to the locked one. The continuous discussion in an inactive thread may mostly be unattended by community users.