Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641#note_154333 > 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. @joel has mentioned to me the `score` at this level should not terminate and I suppose that is based on all users of the call must meet the preconditions and in the case of the direct call from C++ it is not being meet. This would imply the use is invalid and it should be wrapped? I would not do that in the C++ call site. I see the self contained objects API does not return an error and it is also broken: ``` static __inline void rtems_mutex_unlock( rtems_mutex *mutex ) { _Mutex_Release( mutex ); } ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641#note_154333 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-esxry5vfkxbhklv3qobv8wqpf-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
