e6eb0a705b
TL;DR - a complete rewrite. Previously, the prototypical `eventfd()` usage (one thread performing a blocking `read()`, followed by another thread performing a `write()`) would deadlock Zephyr. This shortcoming has existed in Zephyr's `eventfd()` implementation from the start and the suggested workaround was to use `poll()`. However, that is not sufficient for integrating 3rd-party libraries that may rely on proper `eventfd()` blocking operations such as `eventfd_read()` and `eventfd_write()`. The culprit was the per-fdtable-entry `struct k_mutex`. Here we perform a minor revision of the locking strategy and employ `k_condvar_broadcast()` and `k_condvar_wait()` to signal and wait on the holder of a given `struct k_mutex`. It is important to note, however, that the primary means of synchronizing the eventfd state is actually the eventfd spinlock. The fdtable mutex and condition variable are mainly used for the purposes of blocking io (r,w,close) and are not used in the code path of non-blocking reads. The `wait_q` and `k_poll_signal` entries were removed from `struct eventfd` as they were unnecessary. Additionally, switch to using a bitarray because it is possibly faster than linear search for allocating and deallocating eventfd resources. Signed-off-by: Christopher Friedt <cfriedt@meta.com> |
||
|---|---|---|
| .. | ||
| cpp | ||
| hash | ||
| libc | ||
| open-amp | ||
| os | ||
| posix | ||
| smf | ||
| CMakeLists.txt | ||
| Kconfig | ||