Inside the kernel code are a number of asserts that check if the scheduler is suspended and there is a non-zero wait time specified. This is good and catches one class of problems where the API is used in a way that causes problems since it can’t let the current task block if the scheduler is disabled.
The issue is that since it only is testing if the state is ‘suspended’, the other problematic case, that the scheduler hasn’t even been started yet, where it also can’t block isn’t checked for. Rather than testing to see if the scheduler is suspended, it would seem better to test if the scheduler was not running so both cases would be caught, or maybe reverse the condition and assert that either the scheduler is running or the block time is 0
Calling vSemaphoreCreateBinary() (which is the older macro version of the newer xSemaphoreCreateBinary() function) results in a call to xQueueGenericSend() because the semaphore is created set to 1. Therefore this occurrence of the assert you describe can’t be changed without resulting in the assert() being hit if semaphores are created before the scheduler is started. I can’t think of a reason why the others couldn’t be changed though. Probably best for us to try and and check all the test tasks still work correctly. Thanks for the input.
The asserts allow the call if the timeout parameter is set to 0, as that call should probably be using (since it doesn’t want to wait).
The only case that would change would be a call with a non-zero timeout, but you happen to know that it won’t need to wait as nothing is competing for it. This might impact things using a Mutex, or a semaphore being used as a sort of mutex.
That might be enough reason to not change it, but maybe add a test that the scheduler IS running before letting the system crash because it isn’t.