MutexIF::NO_TIMEOUT has different meanings for FreeRTOS and Linux #91
This is a consistency issue. On Linux, MutexIF::NO_TIMEOUT means permanent blocking (not every intuitive in my opinion, permanent blocking should be on the right side of the number spectrum, not the value 0, but something like 0xffffffff, just like the portMAX_DELAY value from FreeRTOS). On FreeRTOS it means polling (try to unlock, if it doesnt work, return MutexIF::TIMEOUT immediately) like expected.
What do you think?
I suggest introducing a new timeout value with the name
SemaphoreIF::MAX_TIMEOUT for semaphores) to perform permanent blocking.
I already introduced this in the pull request #90 which includes Mutex improvements for FreeRTOS.
Rename former NO_TIMEOUT timeout value to
and rename the polling version timeout to
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?