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. 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? Ronny _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
