[Xenomai-help] posix functions for real time and non real time threads

[Xenomai-help] posix functions for real time and non real time threads

[M. Koehrer]

Hi everybody,

I have a fairly huge application that consists of several real time threads and several non real time (posix) threads.
For the non real time threads I use the pthread_create function and e.g. the pthread_mutex_lock/unlock functions to
synchronize them.
Is it possible to use the Xenomai Posix skin for real time threads as well?
When linking against pthread_rt and pthread I have two "variants" of e.g. pthread_create. One to be used for real
time threads and one for the non real time threads. How are they distinguished?
How can I define to create a real time task using pthread_create and how can I define to create a non real time task
using pthread_create.

Thanks for any hints on that issue.

Regards

Mathias

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE NEUEINSTEIGER
Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket
für clevere Doppel-Sparer, nur  29,95 Euro  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] posix functions for real time and non real time threads

[Gilles Chanteperdrix]

On Jan 8, 2008 8:17 AM, M. Koehrer <mathias_koehrer@domain.hid> wrote:
> Hi everybody,
>
> I have a fairly huge application that consists of several real time threads and several non real time (posix) threads.
> For the non real time threads I use the pthread_create function and e.g. the pthread_mutex_lock/unlock functions to
> synchronize them.
> Is it possible to use the Xenomai Posix skin for real time threads as well?
> When linking against pthread_rt and pthread I have two "variants" of e.g. pthread_create. One to be used for real
> time threads and one for the non real time threads. How are they distinguished?
> How can I define to create a real time task using pthread_create and how can I define to create a non real time task
> using pthread_create.

In fact, linking agains pthread_rt is not enough to use Xenomai posix
skin real-time services, in order to get the real-time pthread_create,
you have to add to the link flags of your application
-Wl,--wrap,pthread_create. Note that you do not have to pass the
--wrap yourself, xeno-config --posix-ldflags will pass all the --wrap
flags.

Once you pass the -Wl,--wrap,pthread_create to gcc, all calls to
pthread_create in your code are replaced with calls to
__wrap_pthread_create, and all calls to __real_pthread_create are
replaced with calss to the original, non wrapped, pthread_create.

So, when an application is compiled for Xenomai posix skin, the
pthread_* services are the real-time services, and the
__real_pthread_* services are non real-time services.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[M. Koehrer]

Hi Gilles,

thank you very much for the response.
I tried this out and found one strange thing:
When I run the following simple example (that uses the __real_pthread_ functions)
the executable appears in the /proc/xenomai/stat list.
As I am calling __real_pthread_create() I expected that my program does not appear
in xenomai at all.
Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags 
is used.

Another question:
Is there a special header file available that has some defines to map the pthread_xxx
function to __real_pthread_xxx.
By including this header I do not have to modify the C code of that files that should
use the non real-time functions.

Thanks for any response on that.

Regards

Mathias

-------------- BEGIN OF CODE ---------------
#include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>

#define USE_REAL
pthread_t thread;

void *mytaska(void *cookie)
{
    int i;
    for (i=0; i < 5; i++)
    {
        struct timespec rqtp;
        printf("Task A\n");
        rqtp.tv_sec = 1;
        rqtp.tv_nsec = 0;
#ifdef USE_REAL
        __real_nanosleep(&rqtp, 0);
#else
        nanosleep(&rqtp, 0);
#endif
    }
    return 0;
}

int main(void)
{
    int i;
    mlockall(MCL_CURRENT|MCL_FUTURE);
    printf("pid: %i\n", getpid());
#ifdef USE_REAL
    __real_pthread_create(&thread, NULL, mytaska, NULL);
#else
    pthread_create(&thread, NULL, mytaska, NULL);
#endif
    for (i=0; i<3; i++)
    {
        struct timespec rqtp;
        printf("Main\n");
        rqtp.tv_sec = 1;
        rqtp.tv_nsec = 0;
#ifdef USE_REAL
        __real_nanosleep(&rqtp, 0);
#else
        __nanosleep(&rqtp, 0);
#endif
    }
    pthread_join(thread, NULL);
    printf("Main: A joined\n");
    return 0;
}
------------- END OF CODE ----------


> On Jan 8, 2008 8:17 AM, M. Koehrer <mathias_koehrer@domain.hid> wrote:
> > Hi everybody,
> >
> > I have a fairly huge application that consists of several real time
> threads and several non real time (posix) threads.
> > For the non real time threads I use the pthread_create function and e.g.
> the pthread_mutex_lock/unlock functions to
> > synchronize them.
> > Is it possible to use the Xenomai Posix skin for real time threads as
> well?
> > When linking against pthread_rt and pthread I have two "variants" of e.g.
> pthread_create. One to be used for real
> > time threads and one for the non real time threads. How are they
> distinguished?
> > How can I define to create a real time task using pthread_create and how
> can I define to create a non real time task
> > using pthread_create.
> 
> In fact, linking agains pthread_rt is not enough to use Xenomai posix
> skin real-time services, in order to get the real-time pthread_create,
> you have to add to the link flags of your application
> -Wl,--wrap,pthread_create. Note that you do not have to pass the
> --wrap yourself, xeno-config --posix-ldflags will pass all the --wrap
> flags.
> 
> Once you pass the -Wl,--wrap,pthread_create to gcc, all calls to
> pthread_create in your code are replaced with calls to
> __wrap_pthread_create, and all calls to __real_pthread_create are
> replaced with calss to the original, non wrapped, pthread_create.
> 
> So, when an application is compiled for Xenomai posix skin, the
> pthread_* services are the real-time services, and the
> __real_pthread_* services are non real-time services.
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT FÜR ALLE NEUEINSTEIGER
Jetzt bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket
für clevere Doppel-Sparer, nur  29,95 Euro  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] posix functions for real time and non real time

[Jan Kiszka]

M. Koehrer wrote:
> Hi Gilles,
> 
> thank you very much for the response.
> I tried this out and found one strange thing:
> When I run the following simple example (that uses the __real_pthread_ functions)
> the executable appears in the /proc/xenomai/stat list.
> As I am calling __real_pthread_create() I expected that my program does not appear
> in xenomai at all.
> Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags 
> is used.

POSIX-skin applications automatically map the main thread to a (prio-0)
Xenomai thread, therefore you see at least one thread in /proc/xenomai.
Technically, this happens in the init function of the pthread_rt lib you
link against, and it helps your main thread to interact with Xenomai
resources without explicit (non-standard) thread wrapping.

> 
> Another question:
> Is there a special header file available that has some defines to map the pthread_xxx
> function to __real_pthread_xxx.
> By including this header I do not have to modify the C code of that files that should
> use the non real-time functions.

You are tackling an important issue: How to build large-scale POSIX
applications over Xenomai when they have both RT and non-RT parts?
Possible strategies:

[RT part dominates]
 - Wrap the non-RT calls with "__real_"-prefixes

[Non-RT part dominates]
 - Invoke RT-services explicitly via "__wrap_"-prefixes

[Both cases]
 - Separate RT- and non-RT-only components into separate program
   modules, link them in two steps: first RT with Xenomai args and
   non-RT as usual, then link both intermediate parts together

For this wrapping, I think that renaming macros for pthread services
could indeed be useful (e.g. something that translates
rt_pthread_mutex_lock in the source code into __warp_pthread_mutex_lock
for the linker).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> M. Koehrer wrote:
> > Hi Gilles,
> >
> > thank you very much for the response.
> > I tried this out and found one strange thing:
> > When I run the following simple example (that uses the __real_pthread_ functions)
> > the executable appears in the /proc/xenomai/stat list.
> > As I am calling __real_pthread_create() I expected that my program does not appear
> > in xenomai at all.
> > Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags
> > is used.
>
> POSIX-skin applications automatically map the main thread to a (prio-0)
> Xenomai thread, therefore you see at least one thread in /proc/xenomai.
> Technically, this happens in the init function of the pthread_rt lib you
> link against, and it helps your main thread to interact with Xenomai
> resources without explicit (non-standard) thread wrapping.
>
> >
> > Another question:
> > Is there a special header file available that has some defines to map the pthread_xxx
> > function to __real_pthread_xxx.
> > By including this header I do not have to modify the C code of that files that should
> > use the non real-time functions.
>
> You are tackling an important issue: How to build large-scale POSIX
> applications over Xenomai when they have both RT and non-RT parts?
> Possible strategies:
>
> [RT part dominates]
>  - Wrap the non-RT calls with "__real_"-prefixes
>
> [Non-RT part dominates]
>  - Invoke RT-services explicitly via "__wrap_"-prefixes
>
> [Both cases]
>  - Separate RT- and non-RT-only components into separate program
>    modules, link them in two steps: first RT with Xenomai args and
>    non-RT as usual, then link both intermediate parts together
>
> For this wrapping, I think that renaming macros for pthread services
> could indeed be useful (e.g. something that translates
> rt_pthread_mutex_lock in the source code into __warp_pthread_mutex_lock
> for the linker).

When you try to mix up real-time and non real-time threads, it all
becomes very complicated. You do not need your complication: just make
all your tasks real-time tasks (using priority 0 for low priority
tasks) and forget about __real_* calls.

That said, I will probably create the __xn_pthread_* calls aliases to
__wrap_pthread_* calls, but for an entirely different reason: to let
user applications use --wrap if they need to.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 2:18 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> On Jan 8, 2008 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> > M. Koehrer wrote:
> > > Hi Gilles,
> > >
> > > thank you very much for the response.
> > > I tried this out and found one strange thing:
> > > When I run the following simple example (that uses the __real_pthread_ functions)
> > > the executable appears in the /proc/xenomai/stat list.
> > > As I am calling __real_pthread_create() I expected that my program does not appear
> > > in xenomai at all.
> > > Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags
> > > is used.
> >
> > POSIX-skin applications automatically map the main thread to a (prio-0)
> > Xenomai thread, therefore you see at least one thread in /proc/xenomai.
> > Technically, this happens in the init function of the pthread_rt lib you
> > link against, and it helps your main thread to interact with Xenomai
> > resources without explicit (non-standard) thread wrapping.
> >
> > >
> > > Another question:
> > > Is there a special header file available that has some defines to map the pthread_xxx
> > > function to __real_pthread_xxx.
> > > By including this header I do not have to modify the C code of that files that should
> > > use the non real-time functions.
> >
> > You are tackling an important issue: How to build large-scale POSIX
> > applications over Xenomai when they have both RT and non-RT parts?
> > Possible strategies:
> >
> > [RT part dominates]
> >  - Wrap the non-RT calls with "__real_"-prefixes
> >
> > [Non-RT part dominates]
> >  - Invoke RT-services explicitly via "__wrap_"-prefixes
> >
> > [Both cases]
> >  - Separate RT- and non-RT-only components into separate program
> >    modules, link them in two steps: first RT with Xenomai args and
> >    non-RT as usual, then link both intermediate parts together
> >
> > For this wrapping, I think that renaming macros for pthread services
> > could indeed be useful (e.g. something that translates
> > rt_pthread_mutex_lock in the source code into __warp_pthread_mutex_lock
> > for the linker).
>
> When you try to mix up real-time and non real-time threads, it all
> becomes very complicated. You do not need your complication: just make

I meant "You do not need this complication"

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> On Jan 8, 2008 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> M. Koehrer wrote:
>>> Hi Gilles,
>>>
>>> thank you very much for the response.
>>> I tried this out and found one strange thing:
>>> When I run the following simple example (that uses the __real_pthread_ functions)
>>> the executable appears in the /proc/xenomai/stat list.
>>> As I am calling __real_pthread_create() I expected that my program does not appear
>>> in xenomai at all.
>>> Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags
>>> is used.
>> POSIX-skin applications automatically map the main thread to a (prio-0)
>> Xenomai thread, therefore you see at least one thread in /proc/xenomai.
>> Technically, this happens in the init function of the pthread_rt lib you
>> link against, and it helps your main thread to interact with Xenomai
>> resources without explicit (non-standard) thread wrapping.
>>
>>> Another question:
>>> Is there a special header file available that has some defines to map the pthread_xxx
>>> function to __real_pthread_xxx.
>>> By including this header I do not have to modify the C code of that files that should
>>> use the non real-time functions.
>> You are tackling an important issue: How to build large-scale POSIX
>> applications over Xenomai when they have both RT and non-RT parts?
>> Possible strategies:
>>
>> [RT part dominates]
>>  - Wrap the non-RT calls with "__real_"-prefixes
>>
>> [Non-RT part dominates]
>>  - Invoke RT-services explicitly via "__wrap_"-prefixes
>>
>> [Both cases]
>>  - Separate RT- and non-RT-only components into separate program
>>    modules, link them in two steps: first RT with Xenomai args and
>>    non-RT as usual, then link both intermediate parts together
>>
>> For this wrapping, I think that renaming macros for pthread services
>> could indeed be useful (e.g. something that translates
>> rt_pthread_mutex_lock in the source code into __warp_pthread_mutex_lock
>> for the linker).
> 
> When you try to mix up real-time and non real-time threads, it all
> becomes very complicated. You do not need your complication: just make
> all your tasks real-time tasks (using priority 0 for low priority
> tasks) and forget about __real_* calls.

That can be inefficient in large applications: You don't need the
(average-case) overhead of Xenomai IPC for pure non-RT interaction. And
IPC object creation is precisely the critical point, because their type
cannot be told apart by the wrapping layer based on generic parameters.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > On Jan 8, 2008 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >> M. Koehrer wrote:
> >>> Hi Gilles,
> >>>
> >>> thank you very much for the response.
> >>> I tried this out and found one strange thing:
> >>> When I run the following simple example (that uses the __real_pthread_ functions)
> >>> the executable appears in the /proc/xenomai/stat list.
> >>> As I am calling __real_pthread_create() I expected that my program does not appear
> >>> in xenomai at all.
> >>> Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags
> >>> is used.
> >> POSIX-skin applications automatically map the main thread to a (prio-0)
> >> Xenomai thread, therefore you see at least one thread in /proc/xenomai.
> >> Technically, this happens in the init function of the pthread_rt lib you
> >> link against, and it helps your main thread to interact with Xenomai
> >> resources without explicit (non-standard) thread wrapping.
> >>
> >>> Another question:
> >>> Is there a special header file available that has some defines to map the pthread_xxx
> >>> function to __real_pthread_xxx.
> >>> By including this header I do not have to modify the C code of that files that should
> >>> use the non real-time functions.
> >> You are tackling an important issue: How to build large-scale POSIX
> >> applications over Xenomai when they have both RT and non-RT parts?
> >> Possible strategies:
> >>
> >> [RT part dominates]
> >>  - Wrap the non-RT calls with "__real_"-prefixes
> >>
> >> [Non-RT part dominates]
> >>  - Invoke RT-services explicitly via "__wrap_"-prefixes
> >>
> >> [Both cases]
> >>  - Separate RT- and non-RT-only components into separate program
> >>    modules, link them in two steps: first RT with Xenomai args and
> >>    non-RT as usual, then link both intermediate parts together
> >>
> >> For this wrapping, I think that renaming macros for pthread services
> >> could indeed be useful (e.g. something that translates
> >> rt_pthread_mutex_lock in the source code into __warp_pthread_mutex_lock
> >> for the linker).
> >
> > When you try to mix up real-time and non real-time threads, it all
> > becomes very complicated. You do not need your complication: just make
> > all your tasks real-time tasks (using priority 0 for low priority
> > tasks) and forget about __real_* calls.
>
> That can be inefficient in large applications: You don't need the
> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
> IPC object creation is precisely the critical point, because their type
> cannot be told apart by the wrapping layer based on generic parameters.

The point is that you usually do not care.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> When you try to mix up real-time and non real-time threads, it all
>>> becomes very complicated. You do not need your complication: just make
>>> all your tasks real-time tasks (using priority 0 for low priority
>>> tasks) and forget about __real_* calls.
>> That can be inefficient in large applications: You don't need the
>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
>> IPC object creation is precisely the critical point, because their type
>> cannot be told apart by the wrapping layer based on generic parameters.
> 
> The point is that you usually do not care.
> 

My customer does. :)

E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
stuff does (repeating once again: in the average case).

What I forgot:
> That said, I will probably create the __xn_pthread_* calls aliases to
> __wrap_pthread_* calls, but for an entirely different reason: to let
> user applications use --wrap if they need to.

Just for aesthetic reasons: Can we avoid the leading "__" for this
welcomed alternative?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] posix functions for real time and non real time

[Philippe Gerum]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> Gilles Chanteperdrix wrote:
>>>> When you try to mix up real-time and non real-time threads, it all
>>>> becomes very complicated. You do not need your complication: just make
>>>> all your tasks real-time tasks (using priority 0 for low priority
>>>> tasks) and forget about __real_* calls.
>>> That can be inefficient in large applications: You don't need the
>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
>>> IPC object creation is precisely the critical point, because their type
>>> cannot be told apart by the wrapping layer based on generic parameters.
>> The point is that you usually do not care.
>>
> 
> My customer does. :)
> 
> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
> stuff does (repeating once again: in the average case).
> 

You mean in the non contended case.

-- 
Philippe.

Re: [Xenomai-help] posix functions for real time and non real time

[Jan Kiszka]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> When you try to mix up real-time and non real-time threads, it all
>>>>> becomes very complicated. You do not need your complication: just make
>>>>> all your tasks real-time tasks (using priority 0 for low priority
>>>>> tasks) and forget about __real_* calls.
>>>> That can be inefficient in large applications: You don't need the
>>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
>>>> IPC object creation is precisely the critical point, because their type
>>>> cannot be told apart by the wrapping layer based on generic parameters.
>>> The point is that you usually do not care.
>>>
>> My customer does. :)
>>
>> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
>> stuff does (repeating once again: in the average case).
>>
> 
> You mean in the non contended case.

Specifically, but also

 - the potential need to consider the number of non-RT objects in your
   RT system design (specifically if there are a lot of them)

 - scalability limitations of nklock (which would be stressed more
   intensively by contention cases, or when using message queues)

Only when the number of non-RT objects is small, thus negligible, it is
OK to throw them in the same pot as RT objects. Otherwise, it would be
crazy to merge both sets.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] posix functions for real time and non real time

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> When you try to mix up real-time and non real-time threads, it all
>>>>>> becomes very complicated. You do not need your complication: just make
>>>>>> all your tasks real-time tasks (using priority 0 for low priority
>>>>>> tasks) and forget about __real_* calls.
>>>>> That can be inefficient in large applications: You don't need the
>>>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
>>>>> IPC object creation is precisely the critical point, because their type
>>>>> cannot be told apart by the wrapping layer based on generic parameters.
>>>> The point is that you usually do not care.
>>>>
>>> My customer does. :)
>>>
>>> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
>>> stuff does (repeating once again: in the average case).
>>>
>> You mean in the non contended case.
> 
> Specifically, but also
> 
>  - the potential need to consider the number of non-RT objects in your
>    RT system design (specifically if there are a lot of them)
> 
>  - scalability limitations of nklock (which would be stressed more
>    intensively by contention cases, or when using message queues)
> 
> Only when the number of non-RT objects is small, thus negligible, it is
> OK to throw them in the same pot as RT objects. Otherwise, it would be
> crazy to merge both sets.
> 

I'm not arguing about this, since all arguments I read about so far cut
both ways, and it vastly depends on runtime conditions, and execution
patterns exhibited by the application. In short, we just don't know when
and where it's going to bite hard, but we know that for sure, this may
bite hard at some point, depending on the use case.

My point was about the notion that whatever route you may follow to
implement the contended case (well, reasonable ones, I mean), you are
going to face a scalability issue, and futexes with PI coupling have
their own too. In short, YMMV, but as a matter of fact, the current
Xenomai core is not aimed at supporting large SMP scalability.

This said, the non contended case for Xenomai mutual exclusion objects
in user-space still has to be improved the futex way, and likely the
overhead of syscall interposition by the I-pipe lowered.

-- 
Philippe.

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 4:50 PM, Philippe Gerum <philippe.gerum@domain.hid> wrote:
>
> Jan Kiszka wrote:
> > Philippe Gerum wrote:
> >> Jan Kiszka wrote:
> >>> Gilles Chanteperdrix wrote:
> >>>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >>>>> Gilles Chanteperdrix wrote:
> >>>>>> When you try to mix up real-time and non real-time threads, it all
> >>>>>> becomes very complicated. You do not need your complication: just make
> >>>>>> all your tasks real-time tasks (using priority 0 for low priority
> >>>>>> tasks) and forget about __real_* calls.
> >>>>> That can be inefficient in large applications: You don't need the
> >>>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
> >>>>> IPC object creation is precisely the critical point, because their type
> >>>>> cannot be told apart by the wrapping layer based on generic parameters.
> >>>> The point is that you usually do not care.
> >>>>
> >>> My customer does. :)
> >>>
> >>> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
> >>> stuff does (repeating once again: in the average case).
> >>>
> >> You mean in the non contended case.
> >
> > Specifically, but also
> >
> >  - the potential need to consider the number of non-RT objects in your
> >    RT system design (specifically if there are a lot of them)
> >
> >  - scalability limitations of nklock (which would be stressed more
> >    intensively by contention cases, or when using message queues)
> >
> > Only when the number of non-RT objects is small, thus negligible, it is
> > OK to throw them in the same pot as RT objects. Otherwise, it would be
> > crazy to merge both sets.
> >
>
> I'm not arguing about this, since all arguments I read about so far cut
> both ways, and it vastly depends on runtime conditions, and execution
> patterns exhibited by the application. In short, we just don't know when
> and where it's going to bite hard, but we know that for sure, this may
> bite hard at some point, depending on the use case.
>
> My point was about the notion that whatever route you may follow to
> implement the contended case (well, reasonable ones, I mean), you are
> going to face a scalability issue, and futexes with PI coupling have
> their own too. In short, YMMV, but as a matter of fact, the current
> Xenomai core is not aimed at supporting large SMP scalability.
>
> This said, the non contended case for Xenomai mutual exclusion objects
> in user-space still has to be improved the futex way, and likely the
> overhead of syscall interposition by the I-pipe lowered.

I once thought about mapping a "mutex page" in user-space, and put the
mutex counter on this page. However, this approach has a big drawback:
it will not work on ARM if you want to share the mutex between user
and kernel space. This is the point where I left this idea.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Jan 8, 2008 4:50 PM, Philippe Gerum <philippe.gerum@domain.hid> wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> When you try to mix up real-time and non real-time threads, it all
>>>>>>>> becomes very complicated. You do not need your complication: just make
>>>>>>>> all your tasks real-time tasks (using priority 0 for low priority
>>>>>>>> tasks) and forget about __real_* calls.
>>>>>>> That can be inefficient in large applications: You don't need the
>>>>>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
>>>>>>> IPC object creation is precisely the critical point, because their type
>>>>>>> cannot be told apart by the wrapping layer based on generic parameters.
>>>>>> The point is that you usually do not care.
>>>>>>
>>>>> My customer does. :)
>>>>>
>>>>> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
>>>>> stuff does (repeating once again: in the average case).
>>>>>
>>>> You mean in the non contended case.
>>> Specifically, but also
>>>
>>>  - the potential need to consider the number of non-RT objects in your
>>>    RT system design (specifically if there are a lot of them)
>>>
>>>  - scalability limitations of nklock (which would be stressed more
>>>    intensively by contention cases, or when using message queues)
>>>
>>> Only when the number of non-RT objects is small, thus negligible, it is
>>> OK to throw them in the same pot as RT objects. Otherwise, it would be
>>> crazy to merge both sets.
>>>
>> I'm not arguing about this, since all arguments I read about so far cut
>> both ways, and it vastly depends on runtime conditions, and execution
>> patterns exhibited by the application. In short, we just don't know when
>> and where it's going to bite hard, but we know that for sure, this may
>> bite hard at some point, depending on the use case.
>>
>> My point was about the notion that whatever route you may follow to
>> implement the contended case (well, reasonable ones, I mean), you are
>> going to face a scalability issue, and futexes with PI coupling have
>> their own too. In short, YMMV, but as a matter of fact, the current
>> Xenomai core is not aimed at supporting large SMP scalability.
>>
>> This said, the non contended case for Xenomai mutual exclusion objects
>> in user-space still has to be improved the futex way, and likely the
>> overhead of syscall interposition by the I-pipe lowered.
> 
> I once thought about mapping a "mutex page" in user-space, and put the
> mutex counter on this page. However, this approach has a big drawback:
> it will not work on ARM if you want to share the mutex between user
> and kernel space. This is the point where I left this idea.
> 

Well, as a matter of fact, I would not care that much about such a
"limitation". Day after day, we tell people to use kernel space for
device drivers and keep it free from any application layer, and
additionally that they should use RTDM to write device drivers. Since
the RTDM interface has no obvious reason to rely on basic mutual
exclusion services with the in-kernel driver, no issue would be raised
in the common case.

Albeit slightly overkill, it would even be possible to create a mutual
exclusion building block (which is the desired option) at nucleus level,
and make it aware of platform-specific limitations. For instance, we
could tell it to ignore any direct mapping optimization when virtual
address based cache is in effect.

In any case, use cases depending on kernel-to-user mutual exclusion
would gain or lose nothing, but others, the overwhelming majority, would
get a bunch of cycles back to perform more interesting things than
calling into the Xenomai core.

To sum up:

- kernel-based threads would solely create mutexes with pure syscall
interface (the way it is now), and userland would have to go through
this interface to fiddle with it.
- userland threads would implicitly create optimized mutexes.

-- 
Philippe.

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 6:10 PM, Philippe Gerum <philippe.gerum@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > On Jan 8, 2008 4:50 PM, Philippe Gerum <philippe.gerum@domain.hid> wrote:
> >> Jan Kiszka wrote:
> >>> Philippe Gerum wrote:
> >>>> Jan Kiszka wrote:
> >>>>> Gilles Chanteperdrix wrote:
> >>>>>> On Jan 8, 2008 2:44 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >>>>>>> Gilles Chanteperdrix wrote:
> >>>>>>>> When you try to mix up real-time and non real-time threads, it all
> >>>>>>>> becomes very complicated. You do not need your complication: just make
> >>>>>>>> all your tasks real-time tasks (using priority 0 for low priority
> >>>>>>>> tasks) and forget about __real_* calls.
> >>>>>>> That can be inefficient in large applications: You don't need the
> >>>>>>> (average-case) overhead of Xenomai IPC for pure non-RT interaction. And
> >>>>>>> IPC object creation is precisely the critical point, because their type
> >>>>>>> cannot be told apart by the wrapping layer based on generic parameters.
> >>>>>> The point is that you usually do not care.
> >>>>>>
> >>>>> My customer does. :)
> >>>>>
> >>>>> E.g. note that Xenomai IPC does not scale on SMP like glibc/futux-based
> >>>>> stuff does (repeating once again: in the average case).
> >>>>>
> >>>> You mean in the non contended case.
> >>> Specifically, but also
> >>>
> >>>  - the potential need to consider the number of non-RT objects in your
> >>>    RT system design (specifically if there are a lot of them)
> >>>
> >>>  - scalability limitations of nklock (which would be stressed more
> >>>    intensively by contention cases, or when using message queues)
> >>>
> >>> Only when the number of non-RT objects is small, thus negligible, it is
> >>> OK to throw them in the same pot as RT objects. Otherwise, it would be
> >>> crazy to merge both sets.
> >>>
> >> I'm not arguing about this, since all arguments I read about so far cut
> >> both ways, and it vastly depends on runtime conditions, and execution
> >> patterns exhibited by the application. In short, we just don't know when
> >> and where it's going to bite hard, but we know that for sure, this may
> >> bite hard at some point, depending on the use case.
> >>
> >> My point was about the notion that whatever route you may follow to
> >> implement the contended case (well, reasonable ones, I mean), you are
> >> going to face a scalability issue, and futexes with PI coupling have
> >> their own too. In short, YMMV, but as a matter of fact, the current
> >> Xenomai core is not aimed at supporting large SMP scalability.
> >>
> >> This said, the non contended case for Xenomai mutual exclusion objects
> >> in user-space still has to be improved the futex way, and likely the
> >> overhead of syscall interposition by the I-pipe lowered.
> >
> > I once thought about mapping a "mutex page" in user-space, and put the
> > mutex counter on this page. However, this approach has a big drawback:
> > it will not work on ARM if you want to share the mutex between user
> > and kernel space. This is the point where I left this idea.
> >
>
> Well, as a matter of fact, I would not care that much about such a
> "limitation". Day after day, we tell people to use kernel space for
> device drivers and keep it free from any application layer, and
> additionally that they should use RTDM to write device drivers. Since
> the RTDM interface has no obvious reason to rely on basic mutual
> exclusion services with the in-kernel driver, no issue would be raised
> in the common case.
>
> Albeit slightly overkill, it would even be possible to create a mutual
> exclusion building block (which is the desired option) at nucleus level,
> and make it aware of platform-specific limitations. For instance, we
> could tell it to ignore any direct mapping optimization when virtual
> address based cache is in effect.

... or we can get rid completely of the user-space thing on older
ARMs, since atomic_cmpxchg needs a syscall anyway.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] posix functions for real time and non real time

[Gilles Chanteperdrix]

On Jan 8, 2008 12:39 PM, M. Koehrer <mathias_koehrer@domain.hid> wrote:
> Hi Gilles,
>
> thank you very much for the response.
> I tried this out and found one strange thing:
> When I run the following simple example (that uses the __real_pthread_ functions)
> the executable appears in the /proc/xenomai/stat list.
> As I am calling __real_pthread_create() I expected that my program does not appear
> in xenomai at all.
> Build is done using xeno-config --posix-cflags plus -O2 -Wall. For linking xeno-config --posix-ldflags
> is used.
>
> Another question:
> Is there a special header file available that has some defines to map the pthread_xxx
> function to __real_pthread_xxx.
> By including this header I do not have to modify the C code of that files that should
> use the non real-time functions.

To answer precisely to this question: I really think that adding such
a header would create a source of confusion. The current scheme is
pretty simple use pthread_* variants for real-time, use
__real_pthread_* for the rare case when you do not need real-time, and
I really wish to keep it as simple as it currently is.

-- 
                                               Gilles Chanteperdrix