[Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Luotao Fu]

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

Hi folks,

I got the feeling, that named semaphores in xenomai posix skin don't
work properly. I hacked some simple code to test this and attached the
code to this mail, so that you might have a look of my problem yourself.

In my code the main thread initialize a named Semaphore, locks it up and
than create a thread. The thread initialize a semaphore with the same
name and than tries to lock it. Since the semaphore is already locked by
the main thread, the thread blocks. As the main thread is waiting for
the finishing of the thread. It blocks too. So at this point the
programm should block. I tried two sem lock call in the thread, in one
it calls simply sem_wait() and blocks till the Implosion of the Universe
or the arrival of SIGINT, in the other it calls a sem_timedwait() and
blocks for 5 seconds. Both variants work just fine as normal posix
binay. Once compiled and linked against the xenomai posix library, the
sem_wait() appears however not to block at all and the trhead just
marchs through. the sem_timedwait() quits with a segfault.

I'm quite not understanding this. Have I overlooked something or is
there evtl. a bug in the posix skin?

P.S.
Systemconfiguration
Kernel: Vanilla 2.6.13 patched with adeos-linux-2.6.13-i386-r13.patch
Distr. Debian 3.1
Testhost: vmware 5.0
compiler gcc 3.3.5
Xenomai: 2.0, the most recent version from svn. (just updated it 15 Min.
ago. :-) )

Thanx a lot in advance
Cheers
Luotao Fu

[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 1974 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <pthread.h>
#include <limits.h>
#include <semaphore.h>
#include <pthread.h>
#include <sys/mman.h>
#include <sys/ipc.h>
#include <sys/types.h>
#include <signal.h>
#include <errno.h>
#define THR_AMOUNT 1

char *semName = "/testSem";
struct timespec t;

void *funcA(void *parm){
	sem_t *binSem;
 	if ((binSem = sem_open(semName, O_CREAT)) == SEM_FAILED){
	  	perror("cannot open Semaphore"); 
	  	exit(1);
 	}
	printf("semAdress: %p\n", binSem);
	printf("starting Thread A\n");	
	clock_gettime(CLOCK_REALTIME, &t);
	//while (sem_wait(binSem) == -1 && errno == EINTR)
	//  ;
	t.tv_sec += 5;
	sem_timedwait(binSem, &t);	
	printf("finishing Thread A\n");
 	sem_close(binSem);
	pthread_exit(NULL);
}

int main(int argc, char **argv)
{	
	int co,rc;	
	pthread_t testThread[THR_AMOUNT];
 	pthread_attr_t thrAttr;	
 	struct sched_param param = { .sched_priority = 99 };
	sem_t *binSem;
 	if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) {
 		perror("could not lock memeory\n");
 		exit(1);
 	}
 	if ((binSem = sem_open(semName, O_CREAT)) == SEM_FAILED){
	  	perror("cannot open Semaphore"); 
	  	exit(1);
 	}
	printf("semAdress: %p\n", binSem);
	sem_post(binSem);
 	sem_wait(binSem); 	
	pthread_attr_init(&thrAttr);
 	pthread_attr_setdetachstate(&thrAttr,PTHREAD_CREATE_JOINABLE);
 	pthread_attr_setinheritsched(&thrAttr,PTHREAD_EXPLICIT_SCHED);	
 	pthread_attr_setschedpolicy(&thrAttr,SCHED_FIFO); 
 	pthread_attr_setschedparam(&thrAttr,&param); 
	if ( (rc = pthread_create(&testThread[0],&thrAttr, funcA, NULL))
 	     != 0 ){
 	        fprintf(stderr, "cannot create Threads %s\n", strerror(rc)); 
 		exit(1);
 	}
 	for ( co = 0; co < THR_AMOUNT; co++) {
 		if ( pthread_join(testThread[co], NULL) != 0 ){
 			perror("cannot join Threads");			
 			exit(1);
 		}
 	}
 	if (munlockall() == -1){
 		perror("munlockall failure");
 		exit(1);
 	}
 	sem_close(binSem);
	sem_unlink(semName);
	return 0;
}

Re: [Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Gilles Chanteperdrix]

Luotao Fu wrote:
 > Hi folks,
 > 
 > I got the feeling, that named semaphores in xenomai posix skin don't
 > work properly. I hacked some simple code to test this and attached the
 > code to this mail, so that you might have a look of my problem yourself.

Thanks for reporting, you probably found a bug.

I am on it.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Luotao Fu]

Hi,

Gilles Chanteperdrix wrote:
> Luotao Fu wrote:
>  > Hi folks,
>  > 
>  > I got the feeling, that named semaphores in xenomai posix skin don't
>  > work properly. I hacked some simple code to test this and attached the
>  > code to this mail, so that you might have a look of my problem yourself.
> 
> Thanks for reporting, you probably found a bug.

Thanks Gilles, as you surely have noticed, the sem_open() seems to work
properly, As sem_open() called from different threads returns identical
Pointeradresses to Semaphores with same Name. The magic cookie of the
semaphore structure seemed also be set correctly on
PSE51_NAMED_SEM_MAGIC. The Blocking and Unblocking in a single
Mainthread works also fine. What I found strange is that
sem_trywait_internal() don't return EAGAIN like it should, when called
by sem_wait() on a semaphore blocked by another thread. I'm trying to
rip my testcode further down to finer operational calls to locate the
failure. If I found anything interesting or even useful :-), I'll let
you know. It'll also be nice if you could send a mail, as soon as you
find/solve this problem.

> 
> I am on it.
> 

Thanx
Cheers

Luotao Fu

Re: [Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Gilles Chanteperdrix]

Luotao Fu wrote:
 > Hi folks,
 > 
 > I got the feeling, that named semaphores in xenomai posix skin don't
 > work properly. I hacked some simple code to test this and attached the
 > code to this mail, so that you might have a look of my problem yourself.

There was one issue on POSIX skin side: the sem_timedwait function
was not implemented in Xenomai user-space POSIX library, your code was
hence calling libc sem_timedwait, which accounted for the segfault. The
remaining misbehaviours you observed are due to problems in the example
code.

 > (...)
 > #include <stdio.h>
 > #include <stdlib.h>
 > #include <string.h>
 > #include <fcntl.h>
 > #include <pthread.h>
 > #include <limits.h>
 > #include <semaphore.h>
 > #include <pthread.h>
 > #include <sys/mman.h>
 > #include <sys/ipc.h>
 > #include <sys/types.h>
 > #include <signal.h>
 > #include <errno.h>
 > #define THR_AMOUNT 1
 > 
 > char *semName = "/testSem";
 > struct timespec t;
 > 
 > void *funcA(void *parm){
 > 	sem_t *binSem;
 >  	if ((binSem = sem_open(semName, O_CREAT)) == SEM_FAILED){

When calling sem_open with the O_CREAT flag, you have to pass a "mode"
and most importantly a "value" argument which is the initial value of
the semaphore. Your also make the assumption that 0 is a valid numeric
value for the enum O_RDONLY/O_WRONLY/O_RDWR.


 > 	  	perror("cannot open Semaphore"); 
 > 	  	exit(1);
 >  	}
 > 	printf("semAdress: %p\n", binSem);
 > 	printf("starting Thread A\n");	
 > 	clock_gettime(CLOCK_REALTIME, &t);
 > 	//while (sem_wait(binSem) == -1 && errno == EINTR)
 > 	//  ;
 > 	t.tv_sec += 5;
 > 	sem_timedwait(binSem, &t);	

You should always check the return value of system calls. If you do not
want to clutter your code with these checks, then you can define
something along the lines :

int xsem_timedwait(sem_t *sem, const struct timespect *to)
{
    int rc;

    while ((rc = sem_timedwait(sem, to)) == -1 && errno == EINTR)
         ;
    if (rc == -1 && errno != ETIMEDOUT)
          fatal("unexpected error %d (%s) in sem_timedwait", rc, strerror(rc));

    return rc;
}

And use xsem_timedwait everywhere.

 > 	printf("finishing Thread A\n");
 >  	sem_close(binSem);
 > 	pthread_exit(NULL);
 > }
 > 
 > int main(int argc, char **argv)
 > {	
 > 	int co,rc;	
 > 	pthread_t testThread[THR_AMOUNT];
 >  	pthread_attr_t thrAttr;	
 >  	struct sched_param param = { .sched_priority = 99 };
 > 	sem_t *binSem;
 >  	if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) {
 >  		perror("could not lock memeory\n");
 >  		exit(1);
 >  	}
 >  	if ((binSem = sem_open(semName, O_CREAT)) == SEM_FAILED){

Same remark as above.

 > 	  	perror("cannot open Semaphore"); 
 > 	  	exit(1);
 >  	}
 > 	printf("semAdress: %p\n", binSem);
 > 	sem_post(binSem);
 >  	sem_wait(binSem); 	

Pending on a semaphore is forbidden for non-Xenomai threads, so sem_wait
returns -1 with errno set to EPERM here and the semaphore remains
available, assuming, of course that the call to sem_open was changed to
initialize the semaphore value to 0.

 > 	pthread_attr_init(&thrAttr);
 >  	pthread_attr_setdetachstate(&thrAttr,PTHREAD_CREATE_JOINABLE);
 >  	pthread_attr_setinheritsched(&thrAttr,PTHREAD_EXPLICIT_SCHED);	
 >  	pthread_attr_setschedpolicy(&thrAttr,SCHED_FIFO); 
 >  	pthread_attr_setschedparam(&thrAttr,&param); 
 > 	if ( (rc = pthread_create(&testThread[0],&thrAttr, funcA, NULL))
 >  	     != 0 ){
 >  	        fprintf(stderr, "cannot create Threads %s\n", strerror(rc)); 
 >  		exit(1);
 >  	}
 >  	for ( co = 0; co < THR_AMOUNT; co++) {
 >  		if ( pthread_join(testThread[co], NULL) != 0 ){
 >  			perror("cannot join Threads");			
 >  			exit(1);
 >  		}
 >  	}
 >  	if (munlockall() == -1){
 >  		perror("munlockall failure");
 >  		exit(1);
 >  	}
 >  	sem_close(binSem);
 > 	sem_unlink(semName);
 > 	return 0;
 > }
 > _______________________________________________
 > Xenomai-help mailing list
 > Xenomai-help@domain.hid
 > https://mail.gna.org/listinfo/xenomai-help

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Luotao Fu]

Gilles Chanteperdrix wrote:
> Luotao Fu wrote:
>  > Hi folks,
>  > 
>  > I got the feeling, that named semaphores in xenomai posix skin don't
>  > work properly. I hacked some simple code to test this and attached the
>  > code to this mail, so that you might have a look of my problem yourself.
> 
> There was one issue on POSIX skin side: the sem_timedwait function
> was not implemented in Xenomai user-space POSIX library, your code was
> hence calling libc sem_timedwait, which accounted for the segfault. The
> remaining misbehaviours you observed are due to problems in the example
> code.

Thanx Gilles, I've just sent out another mail to this thread before I
noticed your mail. Well sorry for the delay than. I found the
sem_timedwait in posix_overrides.h
 #define sem_timedwait pse51_sem_timedwait
so I thought it'll be handled by the posix skin.

> 
>  > (...)
>  > 
>  > char *semName = "/testSem";
>  > struct timespec t;
>  > 
>  > void *funcA(void *parm){
>  > 	sem_t *binSem;
>  >  	if ((binSem = sem_open(semName, O_CREAT)) == SEM_FAILED){
> 
> When calling sem_open with the O_CREAT flag, you have to pass a "mode"
> and most importantly a "value" argument which is the initial value of
> the semaphore. Your also make the assumption that 0 is a valid numeric
> value for the enum O_RDONLY/O_WRONLY/O_RDWR.
>

oh, hell yeah, forgot it.

> 
.......
>  > 	sem_post(binSem);
>  >  	sem_wait(binSem); 	
> 
> Pending on a semaphore is forbidden for non-Xenomai threads, so sem_wait
> returns -1 with errno set to EPERM here and the semaphore remains
> available, assuming, of course that the call to sem_open was changed to
> initialize the semaphore value to 0.
>

Well this is interesting. I did have had to test the Return value here.

I'd change the testcode as your advice and give it some more tests.

Thanx
cheers
Luotao Fu

Re: [Xenomai-help] Strangeness in named Semaphores(xenomai posix skin)

[Gilles Chanteperdrix]

Luotao Fu wrote:
 > Thanx Gilles, I've just sent out another mail to this thread before I
 > noticed your mail. Well sorry for the delay than. I found the
 > sem_timedwait in posix_overrides.h
 >  #define sem_timedwait pse51_sem_timedwait
 > so I thought it'll be handled by the posix skin.

posix_overrides.h is used for compilation of the POSIX skin for the
simulator, not for the userspace POSIX skin library.

 > > When calling sem_open with the O_CREAT flag, you have to pass a "mode"
 > > and most importantly a "value" argument which is the initial value of
 > > the semaphore. Your also make the assumption that 0 is a valid numeric
 > > value for the enum O_RDONLY/O_WRONLY/O_RDWR.
 > >
 > 
 > oh, hell yeah, forgot it.

Actually, you do not have to pass O_RDONLY/O_WRONLY/O_RDWR flags to
sem_open. I was mixing sem_open and mq_open. Sorry.

-- 


					    Gilles Chanteperdrix.