Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Author: gch
>>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>>> New Revision: 4210
>>>>>> URL:
>>>>>> Log:
>>>>>> Call __real_pthread_setschedparam in order to inform the libc of the 
>>>>>> scheduling parameters change.
>>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>>> scheduling accuracy) for borderline threads, but it will cause
>>>>> regressions for primary-only threads. I have no idea right now how to
>>>>> make both happy, at least without explicit pthread_setschedparam
>>>>> invocations by the user application.
>>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>>> so we assumed you agreed.
>>> I do not find any hint in that thread that we agreed on changing the
>>> implementation. Rather I took back my suggestion to do it like #4210.
>>> And you proposed to install some signal for syncing glibc /wrt
>>> priorities. When changing something, then I would say explore this path
>>> first.
>> We are used to hear you when you do disagree... So, since you did not
>> answer Philippe mail who said "it is certainly debatable", we assumed
>> you agreed. But we certainly were wrong.

I may have misunderstood that this early statement in the discussion was
still valid after we dug deeper into the topic.

>>> Turning rt_task_set_priority into secondary-mode service is a critical
>>> change, and only the last resort if we consider its current
>>> implementation as totally broken - I wouldn't say it is like that. It's
>>> partially and, unfortunately, silently broken, ie. lacking documentation
>>> about its limitations. But its perfectly OK for primary-only users.
>> No, an important invariant of Xenomai is that the priority scales are
>> synchronized between Xenomai and Linux. So, if Linux does not see the
>> same priority as Xenomai, the implementation is broken. Imagine for
>> instance that your primary-only thread posts an NPTL semaphore, knowing
>> that a switch will not occur so that it will not leave primary mode. If
>> the glibc does not see the correct priority, then a mode switch may
>> occur whereas it should not. This is a bit far-fetched, but who knows
>> what else may happen if the priorities are not synchronized. We
>> absolutely want the priorities to be synchronized.

I understand the deep desire to keep the priorities in sync for those
threads that go to secondary mode (or at least accept occasional switches).

But no one will (OK: should) seriously build a primary-only design based
on assumptions about the glibc locking and syscall behavior. Practice
teaches that this is doomed to break - at latest on next glibc update
(or what other standard third-party lib). Primary-only means only safe
Xenomai services or well-audited library calls. So turning some Xenomai
service into an unsafe one remains a critical step, even if it fixes
other use cases.

> Ok. I am looking at the SIGWINCH change.

Great, TiA.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to