Re: [Xenomai] [xenomai-forge] timer-internal consume a lot of cpu

[Philippe Gerum <rpm@xenomai.org>]

On 12/23/2014 06:36 PM, Ronny Meeus wrote:
> On Thu, Dec 18, 2014 at 6:21 PM, Ronny Meeus <ronny.meeus@gmail.com> 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.