On Thu, Dec 18, 2014 at 4:35 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: > On 2014-12-18 16:30, Gilles Chanteperdrix wrote: >> On Thu, Dec 18, 2014 at 04:25:40PM +0100, Ronny Meeus wrote: >>> On Thu, Dec 18, 2014 at 4:04 PM, Gilles Chanteperdrix >>> <gilles.chanteperd...@xenomai.org> wrote: >>>> On Thu, Dec 18, 2014 at 03:58:52PM +0100, Jan Kiszka wrote: >>>>> On 2014-12-18 15:12, Gilles Chanteperdrix wrote: >>>>>> Otherwise, have you tried some alternate libc, such as musl: >>>>>> http://www.musl-libc.org/ >>>>>> >>>>>> The following blog: >>>>>> http://ewontfix.com/ >>>>>> >>>>>> Seems to show that the musl maintainers try and report glibc bugs >>>>>> and avoid them in their implementation. >>>>>> >>>>>> I have not tried xenomai with musl at all, so, maybe it does not >>>>>> even compile. But maybe just compiling a testcase for the condvar >>>>>> issue with that libc would help know if it has the same issue or >>>>>> not. >>>>> >>>>> Well, like with many of those "light-weight" re-implementations, the are >>>>> "small" issues with bits required for real-time: >>>>> >>>>> http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_mutexattr_setprotocol.c >>>> >>>> On the other hand, no implementation with a clear ENOTSUPP is better >>>> than a partial and buggy implementation that can not be trusted anyway. >>>> >>>> -- >>>> Gilles. >>> >>> Gilles I agree. >>> >>> In the meantime I tried it already. >>> >>> This is indeed the trace I get when running my test application with musl. >>> # ./cond_test_arm >>> # hread_mutexattr_setprotocol: Not supported >>> >>> Cobalt is not an option for us either since in that case all Linux >>> applications will run in low-priority. Next to that we also have a >>> huge priority inversion each time a Linux system call is done. >>> >>> Do we have other options to fix forge? >> >> Well, three options have been proposed if I followed this thread >> correctly: >> - stop using priority inheritance for these internal mutexes, at the >> risk of creating priority inversions >> - switch to priority ceiling (but what will be the ceiling? 99?) > > Likely - part of the reason why that is no general solution. > >> - use cobalt. > > - use a patched glibc
I tried to apply the patch on glibc 2.20 but it looks like the issue is still present. Even if it would be solved with the patch, we force all users of forge to work with a patched version of glibc and to go to 2.20. This might not always be easy. > - fix upstream glibc - non-trivial, as history shows, but long overdue Another option is to implement the priority boost in the copperplate lib. Before the signal is done, change the priority to an equal priority as the task signaling the conditional variable (in case the prio or the waiting task is lower). Once the thread is unblocked, restore the original priority (from the thread that receives the signal). Ronny _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
