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
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
