[Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Xenomai-help] What returns rt_task_self in relation to rt_task_create

[M. Koehrer]

Hi all,

I have a simple question concerning the Xenomai native API:
According to the API documentation, rt_task_self returns the 
address of the caller's task descriptor.
I have now written the following (simple application):
---------- START ----------
#include <stdio.h>
#include <sys/mman.h>
#include <native/task.h>

RT_TASK task_desc;

void mytask(void *cookie)
{
    RT_TASK *tsk = rt_task_self();
    printf("rt_task_self  %p\n"
           "task_desc     %p\n", tsk, &task_desc);
}

int main(void)
{
    mlockall(MCL_CURRENT|MCL_FUTURE);

    rt_task_create(&task_desc, "mytaskname", 0, 80, T_JOINABLE);
    rt_task_start(&task_desc, &mytask, NULL);

    rt_task_join(&task_desc);

    return 0;
}
------------ END -----------

I expect now that rt_task_self() returns exactly the address of the task_desc.
However, a different address is returned. 
The output of the application from above is:
rt_task_self  0x804a050
task_desc     0x8049878

How are those addresses related - how can I find out the descriptor address 
used for rt_task_create() at runtime?

Background of the question:
I want to write an application that uses a couple of similar tasks.
I have to store some task-specific information (internal states...).
Now I am looking for a simple way to get this information at runtime from my task
by calling rt_task_self() (or something similar) to use this address to reach my
additional information.

Thanks for any idea on this.

Regards

Mathias



-- 
Mathias Koehrer
mathias_koehrer@domain.hid


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

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

M. Koehrer wrote:
> Hi all,
> 
> I have a simple question concerning the Xenomai native API:
> According to the API documentation, rt_task_self returns the 
> address of the caller's task descriptor.
> I have now written the following (simple application):
> ---------- START ----------
> #include <stdio.h>
> #include <sys/mman.h>
> #include <native/task.h>
> 
> RT_TASK task_desc;
> 
> void mytask(void *cookie)
> {
>     RT_TASK *tsk = rt_task_self();
>     printf("rt_task_self  %p\n"
>            "task_desc     %p\n", tsk, &task_desc);
> }
> 
> int main(void)
> {
>     mlockall(MCL_CURRENT|MCL_FUTURE);
> 
>     rt_task_create(&task_desc, "mytaskname", 0, 80, T_JOINABLE);
>     rt_task_start(&task_desc, &mytask, NULL);
> 
>     rt_task_join(&task_desc);
> 
>     return 0;
> }
> ------------ END -----------
> 
> I expect now that rt_task_self() returns exactly the address of the task_desc.
> However, a different address is returned. 
> The output of the application from above is:
> rt_task_self  0x804a050
> task_desc     0x8049878
> 
> How are those addresses related - how can I find out the descriptor address 
> used for rt_task_create() at runtime?

The documentation is not precise enough here: what you obtain from
rt_task_self is /some/ task descriptor for the currently running task,
it is not a reference to the same piece of memory containing the task
descriptor. Check the library implementation for further insights.

> 
> Background of the question:
> I want to write an application that uses a couple of similar tasks.
> I have to store some task-specific information (internal states...).
> Now I am looking for a simple way to get this information at runtime from my task
> by calling rt_task_self() (or something similar) to use this address to reach my
> additional information.

If you are on NPTL glibc, set up a __thread variable for the per-thread
information. It will always contain the thread-related data that you
can, e.g., fill in during the thread routine's prologue.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 13:04 +0100, Jan Kiszka wrote:
> M. Koehrer wrote:
> > Hi all,
> > 
> > I have a simple question concerning the Xenomai native API:
> > According to the API documentation, rt_task_self returns the 
> > address of the caller's task descriptor.
> > I have now written the following (simple application):
> > ---------- START ----------
> > #include <stdio.h>
> > #include <sys/mman.h>
> > #include <native/task.h>
> > 
> > RT_TASK task_desc;
> > 
> > void mytask(void *cookie)
> > {
> >     RT_TASK *tsk = rt_task_self();
> >     printf("rt_task_self  %p\n"
> >            "task_desc     %p\n", tsk, &task_desc);
> > }
> > 
> > int main(void)
> > {
> >     mlockall(MCL_CURRENT|MCL_FUTURE);
> > 
> >     rt_task_create(&task_desc, "mytaskname", 0, 80, T_JOINABLE);
> >     rt_task_start(&task_desc, &mytask, NULL);
> > 
> >     rt_task_join(&task_desc);
> > 
> >     return 0;
> > }
> > ------------ END -----------
> > 
> > I expect now that rt_task_self() returns exactly the address of the task_desc.
> > However, a different address is returned. 
> > The output of the application from above is:
> > rt_task_self  0x804a050
> > task_desc     0x8049878
> > 
> > How are those addresses related - how can I find out the descriptor address 
> > used for rt_task_create() at runtime?
> 
> The documentation is not precise enough here: what you obtain from
> rt_task_self is /some/ task descriptor for the currently running task,
> it is not a reference to the same piece of memory containing the task
> descriptor. Check the library implementation for further insights.
> 

A descriptor should always be seen as a reference to an object, not as
the object itself. Said differently, there is no such thing as a
main/unique/specific descriptor for any given object. The doc says
exactly that: you get a valid descriptor to the task by calling
rt_task_self(), but nothing says that this ought to be the unique way of
referencing it. It's merely a kind of pointer, although it's not
implemented as a C pointer. This is the reason why the storage address
of the descriptor itself has no value per se, and nothing should be
derived from it. This is what makes objects shareable betwen kernel and
user-space seamlessly from the user POV.

> > 
> > Background of the question:
> > I want to write an application that uses a couple of similar tasks.
> > I have to store some task-specific information (internal states...).
> > Now I am looking for a simple way to get this information at runtime from my task
> > by calling rt_task_self() (or something similar) to use this address to reach my
> > additional information.
> 
> If you are on NPTL glibc, set up a __thread variable for the per-thread
> information. It will always contain the thread-related data that you
> can, e.g., fill in during the thread routine's prologue.
> 
> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 12:38 +0100, M. Koehrer wrote:
> Hi all,

> Background of the question:
> I want to write an application that uses a couple of similar tasks.
> I have to store some task-specific information (internal states...).
> Now I am looking for a simple way to get this information at runtime from my task
> by calling rt_task_self() (or something similar) to use this address to reach my
> additional information.
> 

Use pthread_getspecific() for obtaining back a TLS data previously
defined by pthread_setspecific(), indexed on a TLS key obtained from
pthread_key_create(). Warning: AFAICT, only pthread_getspecific()
refrain from performing any kind of Linux syscall (in the current NPTL
and older LinuxThreads implementation, that is), thus won't migrate your
RT task to secondary mode when called. The two others could call vanilla
kernel services, so you must use them during non-critical preliminary
init steps of your task.

-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

Philippe Gerum wrote:
> On Wed, 2006-11-22 at 13:04 +0100, Jan Kiszka wrote:
>> M. Koehrer wrote:
>>> Hi all,
>>>
>>> I have a simple question concerning the Xenomai native API:
>>> According to the API documentation, rt_task_self returns the 
>>> address of the caller's task descriptor.
>>> I have now written the following (simple application):
>>> ---------- START ----------
>>> #include <stdio.h>
>>> #include <sys/mman.h>
>>> #include <native/task.h>
>>>
>>> RT_TASK task_desc;
>>>
>>> void mytask(void *cookie)
>>> {
>>>     RT_TASK *tsk = rt_task_self();
>>>     printf("rt_task_self  %p\n"
>>>            "task_desc     %p\n", tsk, &task_desc);
>>> }
>>>
>>> int main(void)
>>> {
>>>     mlockall(MCL_CURRENT|MCL_FUTURE);
>>>
>>>     rt_task_create(&task_desc, "mytaskname", 0, 80, T_JOINABLE);
>>>     rt_task_start(&task_desc, &mytask, NULL);
>>>
>>>     rt_task_join(&task_desc);
>>>
>>>     return 0;
>>> }
>>> ------------ END -----------
>>>
>>> I expect now that rt_task_self() returns exactly the address of the task_desc.
>>> However, a different address is returned. 
>>> The output of the application from above is:
>>> rt_task_self  0x804a050
>>> task_desc     0x8049878
>>>
>>> How are those addresses related - how can I find out the descriptor address 
>>> used for rt_task_create() at runtime?
>> The documentation is not precise enough here: what you obtain from
>> rt_task_self is /some/ task descriptor for the currently running task,
>> it is not a reference to the same piece of memory containing the task
>> descriptor. Check the library implementation for further insights.
>>
> 
> A descriptor should always be seen as a reference to an object, not as
> the object itself. Said differently, there is no such thing as a
> main/unique/specific descriptor for any given object. The doc says
> exactly that: you get a valid descriptor to the task by calling
> rt_task_self(), but nothing says that this ought to be the unique way of
> referencing it. 

The doc talks quite a lot about "_the_ task descriptor address" which
/may/ suggest to the reader that there is only one address. That this
cannot be the case becomes obvious when considering user/kernel or
cross-process usage. Still, clarification at some point can help to
avoid any future misinterpretation.

Suggestion (rt_task_self):

"Return the address of a descriptor for the current task.

Note: The returned descriptor address does not relate to the descriptor
address passed to rt_task_create or similar services."

Jan


PS: Who's supposed to free the descriptor allocated by rt_task_self?
Would some check for pthread_getspecific(__native_tskey) + free() on
task self-destruction make sense? Will not catch all cases, I know.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

RE: [Xenomai-help] What returns rt_task_self in relation tort_task_create

[Daniel Schnell]

Philippe Gerum wrote:
> Use pthread_getspecific() for obtaining back a TLS data previously
> defined by pthread_setspecific(), indexed on a TLS key obtained from
> pthread_key_create(). Warning: AFAICT, only pthread_getspecific()
> refrain from performing any kind of Linux syscall (in the current
> NPTL and older LinuxThreads implementation, that is), thus won't
> migrate your RT task to secondary mode when called. The two others
> could call vanilla kernel services, so you must use them during
> non-critical preliminary init steps of your task.       

Does this mean that if you use pthread_getspecific() inside a user-space
application you will not switch to secondary mode ? I was just
abandoning using TLS because I could not imagine how the NPTL's
functionality can be done without a system call. Is this behaviour
something one can rely on in the future ?

Is there something similar like TLS inside the native API ?


Best regards,


Daniel.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:

[...]

> >>> How are those addresses related - how can I find out the descriptor address 
> >>> used for rt_task_create() at runtime?
> >> The documentation is not precise enough here: what you obtain from
> >> rt_task_self is /some/ task descriptor for the currently running task,
> >> it is not a reference to the same piece of memory containing the task
> >> descriptor. Check the library implementation for further insights.
> >>
> > 
> > A descriptor should always be seen as a reference to an object, not as
> > the object itself. Said differently, there is no such thing as a
> > main/unique/specific descriptor for any given object. The doc says
> > exactly that: you get a valid descriptor to the task by calling
> > rt_task_self(), but nothing says that this ought to be the unique way of
> > referencing it. 
> 
> The doc talks quite a lot about "_the_ task descriptor address" which
> /may/ suggest to the reader that there is only one address. That this
> cannot be the case becomes obvious when considering user/kernel or
> cross-process usage. Still, clarification at some point can help to
> avoid any future misinterpretation.
> 
> Suggestion (rt_task_self):
> 
> "Return the address of a descriptor for the current task.
> 

Agreed.

> Note: The returned descriptor address does not relate to the descriptor
> address passed to rt_task_create or similar services."
> 

Well, it actually does in intra-kernel calls, where rt_task_self()
returns the container object of the base nucleus thread present in the
RT_TASK struct the user passed us, even if nobody should rely on this
fact. I would try to clear any confusion like this:
"The address returned points at a descriptor identifying the calling
task, which might be different from the descriptor address passed to
rt_task_create()."

> Jan
> 
> 
> PS: Who's supposed to free the descriptor allocated by rt_task_self?
> Would some check for pthread_getspecific(__native_tskey) + free() on
> task self-destruction make sense? Will not catch all cases, I know.
> 

We could add that, and the same stuff upon return from the task body
inside the trampoline call, but the only way to solve this with no leak
would be to call the nucleus at each invocation, and not use any cached
descriptor here. Since TLS requires to be operated by the owning task,
there is no point in trying to have a deleted task clean those up
thoroughly.

-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
> We could add that, and the same stuff upon return from the task body
> inside the trampoline call, but the only way to solve this with no leak
> would be to call the nucleus at each invocation, and not use any cached
> descriptor here. Since TLS requires to be operated by the owning task,
> there is no point in trying to have a deleted task clean those up
> thoroughly.
> 

When creating a TLS key, you can specify a cleanup function that get
called when a thread exits (or is canceled).

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] What returns rt_task_self in relation tort_task_create

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

Daniel Schnell wrote:
> Philippe Gerum wrote:
>> Use pthread_getspecific() for obtaining back a TLS data previously
>> defined by pthread_setspecific(), indexed on a TLS key obtained from
>> pthread_key_create(). Warning: AFAICT, only pthread_getspecific()
>> refrain from performing any kind of Linux syscall (in the current
>> NPTL and older LinuxThreads implementation, that is), thus won't
>> migrate your RT task to secondary mode when called. The two others
>> could call vanilla kernel services, so you must use them during
>> non-critical preliminary init steps of your task.       
> 
> Does this mean that if you use pthread_getspecific() inside a user-space
> application you will not switch to secondary mode ? I was just
> abandoning using TLS because I could not imagine how the NPTL's
> functionality can be done without a system call. Is this behaviour
> something one can rely on in the future ?

AFAIK, the TLS ABIs for all relevant architectures are build upon
mechanisms (typically registers, sometimes with further pointer walks)
that avoid syscalls - already for performance reasons.

The only thing I'm not sure of is if all implementations create TLS
space during thread setup or on first access. But as you will likely
fill in data during setup anyway, that should be no practical problem.

> 
> Is there something similar like TLS inside the native API ?

No need for it, at least in user-space. Use what glibc and the kernel
provide to you. Specifically __thread variables are very handy and
efficient.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

RE: [Xenomai-help] What returns rt_task_self in relation tort_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 13:48 +0000, Daniel Schnell wrote:
> Philippe Gerum wrote:
> > Use pthread_getspecific() for obtaining back a TLS data previously
> > defined by pthread_setspecific(), indexed on a TLS key obtained from
> > pthread_key_create(). Warning: AFAICT, only pthread_getspecific()
> > refrain from performing any kind of Linux syscall (in the current
> > NPTL and older LinuxThreads implementation, that is), thus won't
> > migrate your RT task to secondary mode when called. The two others
> > could call vanilla kernel services, so you must use them during
> > non-critical preliminary init steps of your task.       
> 
> Does this mean that if you use pthread_getspecific() inside a user-space
> application you will not switch to secondary mode ?

Yes.

>  I was just
> abandoning using TLS because I could not imagine how the NPTL's
> functionality can be done without a system call. Is this behaviour
> something one can rely on in the future ?

TLS must be stack-based and stack-based accesses are thread-private, so
there is no reason for the kernel to show up here; so there is a good
chance that this behaviour be kept in later releases, but I'm not
maintaining the glibc, so I could not swear it.

In any case, you should check by yourself the behaviour of
pthread_getspecific(), by arming the T_WARNSW bit using
rt_task_set_mode(). If the former call switches to secondary mode, you
would get a SIGXCPU signal. Installing this simple test as some
preliminary consistency check before your application runs for real
would prevent any bad surprise after glibc updates.

> 
> Is there something similar like TLS inside the native API ?
> 

No, basically because it requires to know about the nitty-gritty details
of the pthread implementation, and this is precisely why we should only
rely on the regular TLS implementation.

> 
> Best regards,
> 
> 
> Daniel.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: Re: [Xenomai-help] What returns rt_task_self in

[M. Koehrer]

> On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
> 
> [...]
> 
> 
> Well, it actually does in intra-kernel calls, where rt_task_self()
> returns the container object of the base nucleus thread present in the
> RT_TASK struct the user passed us, even if nobody should rely on this
> fact. I would try to clear any confusion like this:
> "The address returned points at a descriptor identifying the calling
> task, which might be different from the descriptor address passed to
> rt_task_create()."
> 
> > Jan
> > 
> > 
> > PS: Who's supposed to free the descriptor allocated by rt_task_self?
> > Would some check for pthread_getspecific(__native_tskey) + free() on
> > task self-destruction make sense? Will not catch all cases, I know.
> > 
> 
> We could add that, and the same stuff upon return from the task body
> inside the trampoline call, but the only way to solve this with no leak
> would be to call the nucleus at each invocation, and not use any cached
> descriptor here. Since TLS requires to be operated by the owning task,
> there is no point in trying to have a deleted task clean those up
> thoroughly.
What about the idea that it is possible to retrieve the cookie that is used with
rt_task_start() ?
E.g. this could be provided with rt_task_inquire()?
The rt_task_info struct has to be expanded for that.

The main use case for this is that some user specific, task related data
has to be stored. One pointer should be sufficient.
I think, an approach that uses the Xenomai API for that is better than
to rely on TLS or NPTL as it is unclear if related actions lead to an unwanted syscall.

One (very ugly) approach could be to code an address into the name of the task.
This name could be retrieved via rt_task_inquire()...

Mathias

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


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

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
> > We could add that, and the same stuff upon return from the task body
> > inside the trampoline call, but the only way to solve this with no leak
> > would be to call the nucleus at each invocation, and not use any cached
> > descriptor here. Since TLS requires to be operated by the owning task,
> > there is no point in trying to have a deleted task clean those up
> > thoroughly.
> > 
> 
> When creating a TLS key, you can specify a cleanup function that get
> called when a thread exits (or is canceled).
> 

Actually, there are spots where the nucleus forces do_exit() over the
caller, and specifically, when we zap a shadow from the Xenomai context,
then perform a tail scheduling for this zombie over the incoming Linux
context. In such situation, the user-space would not even be informed of
what's been going on, so the cleanup routine would be useless.

-- 
Philippe.

RE: [Xenomai-help] What returns rt_task_self in relation tort_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 15:16 +0100, Philippe Gerum wrote:
> On Wed, 2006-11-22 at 13:48 +0000, Daniel Schnell wrote:
> > Philippe Gerum wrote:
> > > Use pthread_getspecific() for obtaining back a TLS data previously
> > > defined by pthread_setspecific(), indexed on a TLS key obtained from
> > > pthread_key_create(). Warning: AFAICT, only pthread_getspecific()
> > > refrain from performing any kind of Linux syscall (in the current
> > > NPTL and older LinuxThreads implementation, that is), thus won't
> > > migrate your RT task to secondary mode when called. The two others
> > > could call vanilla kernel services, so you must use them during
> > > non-critical preliminary init steps of your task.       
> > 
> > Does this mean that if you use pthread_getspecific() inside a user-space
> > application you will not switch to secondary mode ?
> 
> Yes.
> 
> >  I was just
> > abandoning using TLS because I could not imagine how the NPTL's
> > functionality can be done without a system call. Is this behaviour
> > something one can rely on in the future ?
> 
> TLS must be stack-based

... or local register-based... as Jan pointed out,

>  and stack-based accesses are thread-private, so
> there is no reason for the kernel to show up here; so there is a good
> chance that this behaviour be kept in later releases, but I'm not
> maintaining the glibc, so I could not swear it.
> 
> In any case, you should check by yourself the behaviour of
> pthread_getspecific(), by arming the T_WARNSW bit using
> rt_task_set_mode(). If the former call switches to secondary mode, you
> would get a SIGXCPU signal. Installing this simple test as some
> preliminary consistency check before your application runs for real
> would prevent any bad surprise after glibc updates.
> 
> > 
> > Is there something similar like TLS inside the native API ?
> > 
> 
> No, basically because it requires to know about the nitty-gritty details
> of the pthread implementation, and this is precisely why we should only
> rely on the regular TLS implementation.
> 
> > 
> > Best regards,
> > 
> > 
> > Daniel.
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

M. Koehrer wrote:
>> On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
>>
>> [...]
>>
>>
>> Well, it actually does in intra-kernel calls, where rt_task_self()
>> returns the container object of the base nucleus thread present in the
>> RT_TASK struct the user passed us, even if nobody should rely on this
>> fact. I would try to clear any confusion like this:
>> "The address returned points at a descriptor identifying the calling
>> task, which might be different from the descriptor address passed to
>> rt_task_create()."
>>
>>> Jan
>>>
>>>
>>> PS: Who's supposed to free the descriptor allocated by rt_task_self?
>>> Would some check for pthread_getspecific(__native_tskey) + free() on
>>> task self-destruction make sense? Will not catch all cases, I know.
>>>
>> We could add that, and the same stuff upon return from the task body
>> inside the trampoline call, but the only way to solve this with no leak
>> would be to call the nucleus at each invocation, and not use any cached
>> descriptor here. Since TLS requires to be operated by the owning task,
>> there is no point in trying to have a deleted task clean those up
>> thoroughly.
> What about the idea that it is possible to retrieve the cookie that is used with
> rt_task_start() ?
> E.g. this could be provided with rt_task_inquire()?

Will require a syscall that is orders of magnitude slower than any
__thread variable.

Nevertheless, I don't see a reason why we shouldn't provide such trivial
service via rt_task_inquire. Could serve as a kind of fallback then for
weird architectures with lacking native TLS support. And might be useful
for other purposes as well.

> The rt_task_info struct has to be expanded for that.
> 
> The main use case for this is that some user specific, task related data
> has to be stored. One pointer should be sufficient.
> I think, an approach that uses the Xenomai API for that is better than
> to rely on TLS or NPTL as it is unclear if related actions lead to an unwanted syscall.

The only reason to not rely on TLS support provided by recent NPTL is
that there is no NPTL. I don't share your concerns for the reasons I
wrote in the reply to Daniel.

> 
> One (very ugly) approach could be to code an address into the name of the task.
> This name could be retrieved via rt_task_inquire()...
> 
> Mathias
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Re: [Xenomai-help] What returns rt_task_self in

[Philippe Gerum]

On Wed, 2006-11-22 at 15:16 +0100, M. Koehrer wrote:

> The main use case for this is that some user specific, task related data
> has to be stored. One pointer should be sufficient.
> I think, an approach that uses the Xenomai API for that is better than
> to rely on TLS or NPTL as it is unclear if related actions lead to an unwanted syscall.
> 

Think in terms of probability: what's the probability for our own local
TLS implementation to break after we missed some obscure glibc change VS
the probability for the glibc to suddently emit syscalls for
pthread_getspecific()? Because #1 is much more likely than #2, we should
rely on the regular TLS. IOW, let's not reinvent the wheel, particularly
if it's square.

> One (very ugly) approach could be to code an address into the name of the task.
> This name could be retrieved via rt_task_inquire()...
> 

Unfortunately, this would make no sense when multiple address spaces are
involved (kernel/user-space, different processes). This is why
descriptors should be seen as containers for handles, that eventually
point at some objects.

> Mathias
> 
-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote:
> 
>>Philippe Gerum wrote:
>>
>>>On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
>>>We could add that, and the same stuff upon return from the task body
>>>inside the trampoline call, but the only way to solve this with no leak
>>>would be to call the nucleus at each invocation, and not use any cached
>>>descriptor here. Since TLS requires to be operated by the owning task,
>>>there is no point in trying to have a deleted task clean those up
>>>thoroughly.
>>>
>>
>>When creating a TLS key, you can specify a cleanup function that get
>>called when a thread exits (or is canceled).
>>
> 
> 
> Actually, there are spots where the nucleus forces do_exit() over the
> caller, and specifically, when we zap a shadow from the Xenomai context,
> then perform a tail scheduling for this zombie over the incoming Linux
> context. In such situation, the user-space would not even be informed of
> what's been going on, so the cleanup routine would be useless.

IIRC, rt_task_delete calls pthread_cancel, so tasks deleted with
rt_task_delete should be able to run the cleanups before exiting. The
fact that in some cases (namely, in the case of unclean exit) some
chunks of memory are not deallocated seems acceptable.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 17:34 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote:
> > 
> >>Philippe Gerum wrote:
> >>
> >>>On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
> >>>We could add that, and the same stuff upon return from the task body
> >>>inside the trampoline call, but the only way to solve this with no leak
> >>>would be to call the nucleus at each invocation, and not use any cached
> >>>descriptor here. Since TLS requires to be operated by the owning task,
> >>>there is no point in trying to have a deleted task clean those up
> >>>thoroughly.
> >>>
> >>
> >>When creating a TLS key, you can specify a cleanup function that get
> >>called when a thread exits (or is canceled).
> >>
> > 
> > 
> > Actually, there are spots where the nucleus forces do_exit() over the
> > caller, and specifically, when we zap a shadow from the Xenomai context,
> > then perform a tail scheduling for this zombie over the incoming Linux
> > context. In such situation, the user-space would not even be informed of
> > what's been going on, so the cleanup routine would be useless.
> 
> IIRC, rt_task_delete calls pthread_cancel,

Not in the case of self deletion, it seems.

>  so tasks deleted with
> rt_task_delete should be able to run the cleanups before exiting. The
> fact that in some cases (namely, in the case of unclean exit) some
> chunks of memory are not deallocated seems acceptable.
> 

Problem is: destroying a thread from primary mode _is_ clean too, and
likely often used.

-- 
Philippe.

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2006-11-22 at 17:34 +0100, Gilles Chanteperdrix wrote:
> 
>>Philippe Gerum wrote:
>>
>>>On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote:
>>>
>>>
>>>>Philippe Gerum wrote:
>>>>
>>>>
>>>>>On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
>>>>>We could add that, and the same stuff upon return from the task body
>>>>>inside the trampoline call, but the only way to solve this with no leak
>>>>>would be to call the nucleus at each invocation, and not use any cached
>>>>>descriptor here. Since TLS requires to be operated by the owning task,
>>>>>there is no point in trying to have a deleted task clean those up
>>>>>thoroughly.
>>>>>
>>>>
>>>>When creating a TLS key, you can specify a cleanup function that get
>>>>called when a thread exits (or is canceled).
>>>>
>>>
>>>
>>>Actually, there are spots where the nucleus forces do_exit() over the
>>>caller, and specifically, when we zap a shadow from the Xenomai context,
>>>then perform a tail scheduling for this zombie over the incoming Linux
>>>context. In such situation, the user-space would not even be informed of
>>>what's been going on, so the cleanup routine would be useless.
>>
>>IIRC, rt_task_delete calls pthread_cancel,
> 
> 
> Not in the case of self deletion, it seems.

Is there any reason not to use pthread_exit for self deletion ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] What returns rt_task_self in relation to rt_task_create

[Philippe Gerum]

On Wed, 2006-11-22 at 18:38 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-11-22 at 17:34 +0100, Gilles Chanteperdrix wrote:
> > 
> >>Philippe Gerum wrote:
> >>
> >>>On Wed, 2006-11-22 at 15:03 +0100, Gilles Chanteperdrix wrote:
> >>>
> >>>
> >>>>Philippe Gerum wrote:
> >>>>
> >>>>
> >>>>>On Wed, 2006-11-22 at 14:14 +0100, Jan Kiszka wrote:
> >>>>>We could add that, and the same stuff upon return from the task body
> >>>>>inside the trampoline call, but the only way to solve this with no leak
> >>>>>would be to call the nucleus at each invocation, and not use any cached
> >>>>>descriptor here. Since TLS requires to be operated by the owning task,
> >>>>>there is no point in trying to have a deleted task clean those up
> >>>>>thoroughly.
> >>>>>
> >>>>
> >>>>When creating a TLS key, you can specify a cleanup function that get
> >>>>called when a thread exits (or is canceled).
> >>>>
> >>>
> >>>
> >>>Actually, there are spots where the nucleus forces do_exit() over the
> >>>caller, and specifically, when we zap a shadow from the Xenomai context,
> >>>then perform a tail scheduling for this zombie over the incoming Linux
> >>>context. In such situation, the user-space would not even be informed of
> >>>what's been going on, so the cleanup routine would be useless.
> >>
> >>IIRC, rt_task_delete calls pthread_cancel,
> > 
> > 
> > Not in the case of self deletion, it seems.
> 
> Is there any reason not to use pthread_exit for self deletion ?
> 

I don't see any.

-- 
Philippe.