On 12/23/2014 06:36 PM, Ronny Meeus wrote: > On Thu, Dec 18, 2014 at 6:21 PM, Ronny Meeus <[email protected]> wrote: >>> >>> That implies you know the prios of the involved threads. Doesn't sound >>> like a generic solution either. >>> >>> Jan >>> >> >> I think Xenomai knows the involved threads. >> >> Philippe, >> is the list of waiting threads not kept in the thread object? >> > > Philippe, > any feedback on the discussion from your side? >
Since designing over a blatant glibc bug does not make any sense, the only reasonable option is to work around this issue for Mercury specifically. Cobalt implements PI-aware condvars properly, with an additional optimization which makes them pretty efficient, so I don't see the point in changing for a sub-optimal option, only to fix a long overdue glibc issue. I pushed a work around following a brute force approach to the -next branch, which applies a static temporary boost to the caller about to signal or wait for a PI-enabled condvar. I won't bother for dynamic tracking of priorities for this issue, this would introduce nasty races and would only work for the syncobj abstraction. Besides, if the thread signaling the condvar is the timer manager, the boost would always take place anyway. Hopefully this patch should help fixing the issue on your end. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
