On 12/16/2014 06:36 PM, Ronny Meeus wrote: > On Sun, Dec 7, 2014 at 5:26 PM, Ronny Meeus <ronny.me...@gmail.com> wrote: >> Hello >> >> we are using the xenomai-forge implementation. >> We from time to time see an issue that the timer-internal thread is >> consuming a complete core. It is seen when we send broadcast traffic that >> needs to be handled by the Linux kernel (ARP). >> >> The kernel thread's priority handling the packets in the middle between the >> timer-internal thread and the application thread's priority. All threads run >> on the same core. >> If the priority of the timer-internal is lowered below the kernel thread, >> the load disappears immediately. >> So it looks like there is some busy polling on a common resource that is >> currently held by the application thread running at the lowest prio. >> >> I see that the timer lock being used is a mutex with priority inheritance so >> I would expect that the prio of the application is raised as soon as the >> timer-internal thread tries to obtain the mutex. > > After investigating this issue in more detail I have the impression that it > has > nothing to do with the mutex used to protect the timer but with the > conditional > variable used to implement the psos event interface. > > I found references on the web that explain an issue with the internal mutex > used > inside the posix library to implement a conditional variable. See: > https://bugzilla.redhat.com/show_bug.cgi?id=438484 > http://marc.info/?t=134688711000002&r=1&w=2 > > If this is indeed true, it means that the usage of conditional > variables is not safe > at all (from priority inheritance point of view).
Yes, condvars are known not to work nicely with PI mutexes on the glibc. > > Did anybody experiences issues like this before? > Are there any solutions / workarounds available (for example by avoiding using > conditional variables and using PI mutexes instead)? Disabling PI for mutexes is the only option. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
