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

[Chris Johns (@chris)]

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


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