RTEMS | C++ std::mutex has no error checks (#5641)

[Wayne Thornton (@wmthornton-dev)]

Wayne Thornton commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641#note_154277


As I read and understand this (and correct me if I'm wrong), the behavior noted here is rooted in the C++ standard. Under `thread.mutex.requirements.mutex`, unlocking a mutex owned by another thread is explicitly defined as Undefined Behavior. Furthermore, `std::mutex::unlock()` is marked `noexcept` in C++11 and later.

Because `unlock()` is `noexcept`, libstdc++ cannot throw a `std::system_error` even if `__gthread_mutex_unlock` returned an error code (such as `EPERM`). If an exception were thrown, the runtime would immediately trigger `std::terminate()`.

Since C++ exceptions are forbidden here by the standard, converting this check to a fatal system error (or abort) is the only viable way to notify developers of the precondition violation at runtime.

There are a couple of ways around this as I see it:

1) Clearly document that C++ mutex concurrency validation relies on `RTEMS_DEBUG`. In standard C++, violating mutex ownership is Undefined Behavior, and catching Undefined Behavior during development requires debug builds.

2) We should benchmark the CPU cycle and code-size impact of changing `_Assert( mutex->Queue.Queue.owner == executing );` to an always-enabled fatal check (or introducing a build directive such as `RTEMS_FATAL_ON_MUTEX_MISUSE`). If the benchmark overhead of checking `owner == executing` during `_Mutex_Release` is negligible, promoting this from a debug assert to a fatal error would prevent silent queue corruption in safety-critical release builds without violating C++ exception semantics.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641#note_154277
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-5hpb6ma23qscl5rlbh5klbbmh-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260710/e9b69ff1/attachment-0001.htm>