MutexIF::NO_TIMEOUT has different meanings for FreeRTOS and Linux #91

New Issue

muellerr · 2020-05-29T14:23:42+02:00

muellerr commented

2020-05-29 14:23:42 +02:00

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 MutexIF::MAX_TIMEOUT (or SemaphoreIF::MAX_TIMEOUT for semaphores) to perform permanent blocking.

I already introduced this in the pull request #90 which includes Mutex improvements for FreeRTOS.

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 `MutexIF::MAX_TIMEOUT` (or `SemaphoreIF::MAX_TIMEOUT` for semaphores) to perform permanent blocking. I already introduced this in the pull request #90 which includes Mutex improvements for FreeRTOS.

muellerr added the

feature

help wanted

labels 2020-05-29 14:23:42 +02:00

muellerr commented

2020-06-02 13:27:09 +02:00

Second suggestion:

Rename former NO_TIMEOUT timeout value to BLOCKING

and rename the polling version timeout to POLLING

Second suggestion: Rename former NO_TIMEOUT timeout value to `BLOCKING` and rename the polling version timeout to `POLLING`

muellerr referenced a pull request that will close this issue

2020-06-10 18:39:25 +02:00