On 2014-12-18 13:28, Ronny Meeus wrote: > On Thu, Dec 18, 2014 at 10:04 AM, Jan Kiszka <[email protected]> wrote: >> On 2014-12-18 09:00, Ronny Meeus wrote: >>>> >>>> A release of the glibc that fixes this issue. I must admit that I did >>>> not track this problem lately. Jan likely knows better here. >>>> >>> >>> Jan, >>> >>> what version glibc solves the priority inversion issue on conditional >>> variables? >>> I already tried the glibc 2.18 but the issue is still there. >> >> The bug is still not fixed, and discussion stalled again, see >> https://sourceware.org/bugzilla/show_bug.cgi?id=11588 >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RTC ITP SES-DE >> Corporate Competence Center Embedded Linux > > 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. > > Since the pSOS skin uses conditional variables to implement events and > realtime > priority threads to implement pSOS tasks, it is by definition broken > and not useable > for any real application. > > For example the internal-timer server, sending events to lower priority tasks, > will be blocked until all middle prio tasks have completed. We have seen > massive load consumed by the internal-timer server due to this. > What happens is that the timer thread is blocked on the mutex currently owned > by an thread running at normal (lower) priority. Every time a Linux > timer expires, > a signal is sent to the timer-server which will wake-up the task, > return to the c-library > which will re-invoke the futex call. In case a high number of timers > is used, the overhead > of this can be large. Since the timer-server is running at the highest > priority (-100) we > see all kinds of strange crashes. > > The same priority inversion is true for our own drivers since they are > running at > high prio as well. > > Has the replacement of these conditional variables by some other POSIX > mechanism > (like mutexes) ever been considered? Sometimes it is possible to design a algorithm that uses a semaphore for event signaling instead. Doesn't work for all cond-var scenarios, though. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
