45ea83af89
The cmsis implementations of osMutex was trying to inspect internal k_mutex state (the owner and lock count) in the process of trying to acquire the lock. This is unfixably racy, by definition other contexts will be trying to do the same on the unsynchronized data. As far as I can tell, the only purpose was to be able to synthesize osMutex's specified error behavior, which we can do with the existing return codes from k_mutex_lock(). Add similar logic to osSemaphore, which didn't have the race but was likewise abusing access to kernel internals. Signed-off-by: Andy Ross <andyross@google.com> |
||
|---|---|---|
| .. | ||
| cmsis_rtos_v1 | ||
| cmsis_rtos_v2 | ||
| CMakeLists.txt | ||
| Kconfig | ||