[Xenomai-help] pthread_mutex_lock returns 1

[Xenomai-help] pthread_mutex_lock returns 1

[Landau, Bracha]

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

I have a xenomai-based application basically working on my mpc8272 based board. pthread_mutex_lock generally works (and returns zero), but in some cases returns 1 (yes, positive, not negative) which is an unknown error.
Any idea why this may be happening?



________________________________
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@domain.hid and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00

[-- Attachment #2: Type: text/html, Size: 2134 bytes --]

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Gilles Chanteperdrix]

Landau, Bracha wrote:
> I have a xenomai-based application basically working on my mpc8272 based
> board. pthread_mutex_lock generally works (and returns zero), but in
> some cases returns 1 (yes, positive, not negative) which is an unknown
> error.
> Any idea why this may be happening?

1 is not an unknown error, it is EPERM. And the POSIX spec mandates that
errors returned by pthread_* services are the error status. They are not
stored in errno. This is even documented in Xenomai pthread_mutex_lock
documentation:

Returns:
    0 on success

    an error number if:

        * EPERM, the caller context is invalid;
	(...)
        * EPERM, the mutex is not process-shared and does not belong to
the current process;

(...)
Valid contexts:

        * Xenomai kernel-space thread;
        * Xenomai user-space thread (switches to primary mode).

I use the following script to convert back and forth between libc errors
and their value:

#! /bin/sh

sed  "s,#define\t\(.*\b$1\b.*\)/\*\(.*\)\*/,\1\2,;t;d" /usr/include/asm*/errno*



> ------------------------------------------------------------------------
> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of this
> message or any attachments by anyone other than the intended recipient
> is strictly prohibited.

If this message is confidential, why do you send it to a public mailing
list in the first place? Should we unsubscribe you from the mailing list
to preserve your confidentiality?

-- 
                                          Gilles

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Landau, Bracha]

Thanks for your help.

I tried to put in "printk"s in the kernel implementation of the xenomai pthread_mutex_lock, and it did not work. Neither did xnprintf. I did this in order to find out what is the exact cause of the error; generally adding printk's in the kernel implementation of functions did work, but on this one it didn't.

Is there any way to discern what exactly the problem is? This code was working on earlier versions of Xenomai (2.2) and did not generate an error on this instance of calling pthread_mutex_lock.

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Sent: Monday, June 29, 2009 5:32 PM
To: Landau, Bracha
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] pthread_mutex_lock returns 1

Landau, Bracha wrote:
> I have a xenomai-based application basically working on my mpc8272
> based board. pthread_mutex_lock generally works (and returns zero),
> but in some cases returns 1 (yes, positive, not negative) which is an
> unknown error.
> Any idea why this may be happening?

1 is not an unknown error, it is EPERM. And the POSIX spec mandates that errors returned by pthread_* services are the error status. They are not stored in errno. This is even documented in Xenomai pthread_mutex_lock
documentation:

Returns:
    0 on success

    an error number if:

        * EPERM, the caller context is invalid;
        (...)
        * EPERM, the mutex is not process-shared and does not belong to the current process;

(...)
Valid contexts:

        * Xenomai kernel-space thread;
        * Xenomai user-space thread (switches to primary mode).

I use the following script to convert back and forth between libc errors and their value:

#! /bin/sh

sed  "s,#define\t\(.*\b$1\b.*\)/\*\(.*\)\*/,\1\2,;t;d" /usr/include/asm*/errno*



> ----------------------------------------------------------------------
> -- This e-mail is confidential, the property of NDS Ltd and intended
> for the addressee only. Any dissemination, copying or distribution of
> this message or any attachments by anyone other than the intended
> recipient is strictly prohibited.

If this message is confidential, why do you send it to a public mailing list in the first place? Should we unsubscribe you from the mailing list to preserve your confidentiality?

--
                                          Gilles


This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@domain.hid and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Gilles Chanteperdrix]

Landau, Bracha wrote:
> Thanks for your help.
> 
> I tried to put in "printk"s in the kernel implementation of the
> xenomai pthread_mutex_lock, and it did not work. Neither did
> xnprintf. I did this in order to find out what is the exact cause of
> the error; generally adding printk's in the kernel implementation of
> functions did work, but on this one it didn't.
> 
> Is there any way to discern what exactly the problem is? This code
> was working on earlier versions of Xenomai (2.2) and did not generate
> an error on this instance of calling pthread_mutex_lock.

Either your mutex is not process-shared and you try to use it from a
different process (if that is the case, that is easy to know, you did
not call pthread_mutexattr_setpshared, and you try to access the mutex
from a different process, because you called fork after
pthread_mutex_init for instance, see
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Mixing_fork_with_Xenomai_POSIX_skin_services.
)

Or you are trying to lock the mutex from a thread which is not a Xenomai
thread (that is, a thread created with __real_pthread_create, or in some
part of the code where pthread_create is not wrapped with Xenomai POSIX
skin's compilation flags).

You do not tell us with what version of Xenomai you have the problem. If
this is 2.5-rc2, it is normal that you do not see your printks: the
mutexes fast path is now handled in user-space (so, now that you mention
it, I wonder if the pshared attribute works, so, you may have
pthread_mutex_lock which does not fail when it is handled in user-space,
and which fails when it has to go through kernel-space).


> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of
> this message or any attachments by anyone other than the intended
> recipient is strictly prohibited.

Please be informed that since you send this mail to a public mailing
list, we cannot fulfil these requirements in any other way than by
preventing you from posting to the list.

-- 
                                          Gilles

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Landau, Bracha]

I'm using Xenomai version 2.4.

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Sent: Tuesday, June 30, 2009 10:53 AM
To: Landau, Bracha
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] pthread_mutex_lock returns 1

Landau, Bracha wrote:
> Thanks for your help.
>
> I tried to put in "printk"s in the kernel implementation of the
> xenomai pthread_mutex_lock, and it did not work. Neither did xnprintf.
> I did this in order to find out what is the exact cause of the error;
> generally adding printk's in the kernel implementation of functions
> did work, but on this one it didn't.
>
> Is there any way to discern what exactly the problem is? This code was
> working on earlier versions of Xenomai (2.2) and did not generate an
> error on this instance of calling pthread_mutex_lock.

Either your mutex is not process-shared and you try to use it from a different process (if that is the case, that is easy to know, you did not call pthread_mutexattr_setpshared, and you try to access the mutex from a different process, because you called fork after pthread_mutex_init for instance, see http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Mixing_fork_with_Xenomai_POSIX_skin_services.
)

Or you are trying to lock the mutex from a thread which is not a Xenomai thread (that is, a thread created with __real_pthread_create, or in some part of the code where pthread_create is not wrapped with Xenomai POSIX skin's compilation flags).

You do not tell us with what version of Xenomai you have the problem. If this is 2.5-rc2, it is normal that you do not see your printks: the mutexes fast path is now handled in user-space (so, now that you mention it, I wonder if the pshared attribute works, so, you may have pthread_mutex_lock which does not fail when it is handled in user-space, and which fails when it has to go through kernel-space).


> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of this
> message or any attachments by anyone other than the intended recipient
> is strictly prohibited.

Please be informed that since you send this mail to a public mailing list, we cannot fulfil these requirements in any other way than by preventing you from posting to the list.

--
                                          Gilles


This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@domain.hid and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Gilles Chanteperdrix]

Landau, Bracha wrote:
> I'm using Xenomai version 2.4.

Anyway, in xenomai 2.2, mutexes were pshared by default, and there was
no way to do otherwise. After hearing critics from a well-known person
involved in the preempt_rt Linux kernel development, I implemented the
pshared attribute. So, to get mutexes the old way, you have to set the
pshared attribute. Note however, that when you use the pshared
attribute, mutexes are no longer automatically destroyed upon process
deletion.

And also note that if you simply get this problem because you call
pthread_mutex_init, then fork, then use the mutexes in the child
process, you can avoid the problem by calling pthread_mutex_init in the
child process. As explained here:

http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Mixing_fork_with_Xenomai_POSIX_skin_services.


> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of
> this message or any attachments by anyone other than the intended
> recipient is strictly prohibited.

Grrrmblmbl

-- 
                                          Gilles

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Gilles Chanteperdrix]

Landau, Bracha wrote:
> Thanks for your help.
> 
> I tried to put in "printk"s in the kernel implementation of the
> xenomai pthread_mutex_lock, and it did not work. Neither did
> xnprintf. I did this in order to find out what is the exact cause of
> the error; generally adding printk's in the kernel implementation of
> functions did work, but on this one it didn't.

That is because the implementation of the pthread_mutex_lock service is
in ksrc/skins/posix/syscall.c, and calls pse51_mutex_timedlock_break in
ksrc/skins/posix/mutex.c, pthread_mutex_lock implementation in
ksrc/skins/posix/mutex.c is only for kernel-space users. We had to split
this for correct handling of Linux signals.

> 
> Is there any way to discern what exactly the problem is? This code
> was working on earlier versions of Xenomai (2.2) and did not generate
> an error on this instance of calling pthread_mutex_lock.

Ok, I have checked, 2.2 already had the pshared attribute, so I think
your issue is the other one (calling phtread_mutex services from non
real-time threads). Or maybe some other undocumented reason, which you
should find by adding printks... :-)


> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of
> this message or any attachments by anyone other than the intended
> recipient is strictly prohibited.

Did I tell you that I found these footers stupid?

-- 
                                          Gilles

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Landau, Bracha]

 Thanks.

The mutex failed in the function pse51_mutex_trylock_internal, in the following section (the printk is mine):

#if XENO_DEBUG(POSIX)
        if (mutex->owningq != pse51_kqueues(mutex->attr.pshared))
        {
                printk ("mutex->owningq\n");
                return EPERM;
        }
#endif /* XENO_DEBUG(POSIX) */

I have XENO_DEBUG defined.

What does this mean?

(BTW, nothing I can do about those footers.)

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Sent: Tuesday, June 30, 2009 11:18 AM
To: Landau, Bracha
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] pthread_mutex_lock returns 1

Landau, Bracha wrote:
> Thanks for your help.
>
> I tried to put in "printk"s in the kernel implementation of the
> xenomai pthread_mutex_lock, and it did not work. Neither did xnprintf.
> I did this in order to find out what is the exact cause of the error;
> generally adding printk's in the kernel implementation of functions
> did work, but on this one it didn't.

That is because the implementation of the pthread_mutex_lock service is in ksrc/skins/posix/syscall.c, and calls pse51_mutex_timedlock_break in ksrc/skins/posix/mutex.c, pthread_mutex_lock implementation in ksrc/skins/posix/mutex.c is only for kernel-space users. We had to split this for correct handling of Linux signals.

>
> Is there any way to discern what exactly the problem is? This code was
> working on earlier versions of Xenomai (2.2) and did not generate an
> error on this instance of calling pthread_mutex_lock.

Ok, I have checked, 2.2 already had the pshared attribute, so I think your issue is the other one (calling phtread_mutex services from non real-time threads). Or maybe some other undocumented reason, which you should find by adding printks... :-)


> This e-mail is confidential, the property of NDS Ltd and intended for
> the addressee only. Any dissemination, copying or distribution of this
> message or any attachments by anyone other than the intended recipient
> is strictly prohibited.

Did I tell you that I found these footers stupid?

--
                                          Gilles


This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@domain.hid and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00

Re: [Xenomai-help] pthread_mutex_lock returns 1

[Gilles Chanteperdrix]

Landau, Bracha wrote:
>  Thanks.
> 
> The mutex failed in the function pse51_mutex_trylock_internal, in the following section (the printk is mine):
> 
> #if XENO_DEBUG(POSIX)
>         if (mutex->owningq != pse51_kqueues(mutex->attr.pshared))
>         {
>                 printk ("mutex->owningq\n");
>                 return EPERM;
>         }
> #endif /* XENO_DEBUG(POSIX) */
> 
> I have XENO_DEBUG defined.
> 
> What does this mean?

This means that the mutex you lock does not belong to the process which
tries to lock it.

A program which does:

pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL);
pid = fork();
if (pid) {
	assert(pthread_mutex_lock(&mutex) == 0);
}

will fail for reasons I already explained (both in the two previous
answers I sent you, and in the howto I pointed you to, which also
explains how to solve this issue). I am aware that this is not the
behaviour of Linux, but changing in Xenomai is not easy.

> 
> (BTW, nothing I can do about those footers.)

Yes you can. Use a yahoo, gmail, or even a hotmail account. According to
this footer, letting your mails pass to the mailing lists would allow
your company's legal department to bother us. Because letting this mail
pass to a public mailing list is "strictly prohibited", these are the
words of the footer.

-- 
                                          Gilles