> Philippe, Jan
>>
>> as long as this issue is not fixed in glibc, it is not OK to use
>> conditional variables
>> in application space for real-time applications in my opinion.
>
> ...when combining them with PI mutexes, right. For real-time QEMU/KVM, I
> worked around this by using prio-ceiling mutexes. That is by far not
> optimal, performance-wise, but at least you avoid random lockups or the
> other side effects of that bug.
>
Jan, to be clear:
We do not use PI mutexes in our application, we just use pSOS primitives.
Internally in the copperplate lib (see copperplate/syncobj.c), conditional vars
are used in combination with PI mutexes.
static inline
int monitor_wait_grant(struct syncobj *sobj,
struct threadobj *current,
const struct timespec *timeout)
{
if (timeout)
return -pthread_cond_timedwait(¤t->core.grant_sync,
&sobj->core.lock, timeout);
return -pthread_cond_wait(¤t->core.grant_sync, &sobj->core.lock);
}
where sobj->core.lock is a mutex with PI:
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
ret = __bt(-pthread_mutexattr_setpshared(&mattr, mutex_scope_attribute));
Ronny
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
