[Xenomai] libalchemy: failing test case task-5

[Xenomai] libalchemy: failing test case task-5

[Jan Kiszka]

Hi,

I played a bit with the native skin emulation in Xenomai 3. The shipped
test cases in lib/alchemy/testsuite point a problem:
rt_task_set_priority is no longer a pure real-time services. As it calls
libc's pthread_setschedparam internally, it will - at least briefly -
switch the caller to secondary mode. This break the task-5 test which
assumes a different behaviour.

Are there ideas/plans to address this issues? Are there more case known
where the new architecture provides some challenges when trying to
preserve original API semantics?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] libalchemy: failing test case task-5

[Philippe Gerum]

On 09/24/2013 08:32 PM, Jan Kiszka wrote:
> Hi,
>
> I played a bit with the native skin emulation in Xenomai 3. The shipped
> test cases in lib/alchemy/testsuite point a problem:
> rt_task_set_priority is no longer a pure real-time services. As it calls
> libc's pthread_setschedparam internally, it will - at least briefly -
> switch the caller to secondary mode. This break the task-5 test which
> assumes a different behaviour.
>
> Are there ideas/plans to address this issues?

The switch to secondary mode will remain, the 2.6 implementation is even 
worse actually. We have to keep both schedulers in sync, and for that, 
the glibc has to be notified about the policy/priority change as well. 
In 2.6, the target thread would receive a SIGSHADOW notification, 
causing it to switch to secondary mode, while the setschedparam caller 
would remain in primary mode. With 3.x, this is reversed: the thread 
which issues the request does the switch, but the target thread whose 
priority/policy was changed does not.

At the very least, this behavior is much saner, since the issuer has to 
be aware of the consequences of its request, and the target thread won't 
move to secondary in a random fashion with respect to its code flow. In 
addition, this lifts a potential deadlock situation, as 
pthread_setschedparm is not async-safe, so running it over a SHIGSHADOW 
handler is not that safe.

Are there more case known
> where the new architecture provides some challenges when trying to
> preserve original API semantics?
>

All user-visible changes are tracked in an internal document here. I'll 
publish it right after the Cobalt/POSIX extension model with Xenomai 3 
is fully validated, since this might have a few implications more.

-- 
Philippe.