Issue created by Chris Johns:
https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641
## Summary
In C++ and `std::mutex` you can release a mutex when you are not the owner and
no exception with the error is raise. This is a result of how C++ maps to the
RTEMS interfaces and how GCC's C++ implementation works.
RTEMS's GCC C++ support maps directly to the `score` mutex structure:
```
typedef struct _Mutex_Control __gthread_mutex_t;
typedef struct _Mutex_recursive_Control __gthread_recursive_mutex_t;
```
The code to lock and lock and unlock a mutex is:
```
static inline int
__gthread_mutex_lock (__gthread_mutex_t *__mutex)
{
_Mutex_Acquire (__mutex);
return 0;
}
```
```
static inline int
__gthread_mutex_unlock (__gthread_mutex_t *__mutex)
{
_Mutex_Release (__mutex);
return 0;
}
```
The `score` code has an assert to check if the mutex is owned by the executing
thread that is only enabled when you build with `RTEMS_DEBUG` otherwise the
error is silently ignored:
```
_Assert( mutex->Queue.Queue.owner == executing );
```
Fixing the RTEMS `score` code to return an error and the support code in GCC
will not help as GCC's unlock code is:
```
void
unlock()
{
// XXX EINVAL, EAGAIN, EBUSY
__gthread_mutex_unlock(&_M_mutex);
}
```
If these asserts became fatal errors C++ users would know there is a problem?
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641
You're receiving this email because of your account on gitlab.rtems.org.
Unsubscribe from this thread:
https://gitlab.rtems.org/-/sent_notifications/4-a8mlabf4sdkm2kj7zubottav4-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
