pthread's mutex question
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Apr 30 13:24:03 UTC 2002
John Ford wrote:
>
> Pattara Kiatisevi writes:
> > On Mon, 29 Apr 2002, Joel Sherrill wrote:
> >
> > >
> > >
> > > Pattara Kiatisevi wrote:
> > > >
> > > > Hi again,
> > > >
> > > > I have played with pthread's mutex with this small code:
> > > >
> > > > pthread_mutex_t a,b;
> > > >
> > > > printf("Initialize mutexes...\n");
> > > > pthread_mutex_init(&a, NULL);
> > > > pthread_mutex_init(&b, NULL);
> > > >
> > > > printf("Trying to lock mutex a..\n");
> > > > pthread_mutex_lock(&a);
> > > > printf("Got mutex a..\n");
> > > >
> > > > printf("Trying to lock mutex a..\n");
> > > > pthread_mutex_lock(&a); <----------should block here
> > > > printf("Got mutex a..\n");
> > > >
> > > > fprintf(stderr,"Done.\n");
> > > >
> > > > On Linux, the program will block forever at the second attempt to lock
> > > > mutex a but on RTEMS it doesn't block. Instead it returns with value 45.
> > > > Is there any chance to have it blocked here in RTEMS?
> > >
> > > That's EDEADLOCK which probably means you are attempting to acquire
> > > a mutex you already own.
> >
> > Yeah and normally the second lock should block? Or is there any adjustable
> > parameter?
>
> This is an undefined result using POSIX threads. The second call can
> either return EDEADLOCK, or it can simply honor your request and
> deadlock the task. It is implementation dependent, meaning that you
> should never rely on it working one way or the other. Obviously RTEMS
> and Linux implement it differently. I much prefer the RTEMS way!
> Silent deadlock is not my idea of fun...
I agree and it looks like the Open Group UNIX98 standard has
fine-tuned the application options a bit.
RTEMS has a mutex attribute called "recursive" to set the desired
behavior but the general RTEMS philosophy is to not let you trip
over your own feet. :)
> John
>
> >
> > > Also ... What target and BSP are you using? If accidentally
> > > using unix/posix that is an impact since RTEMS POSIX API
> > > can't be used there.
> >
> > sparc-rtems/leon2.
> >
> > Thank you,
> > Pattara
> >
> > >
> > > > Regards,
> > > > Pattara
> > > >
> > > > --
> > > > Please avoid sending me Word or PowerPoint attachments.
> > > > See http://www.fsf.org/philosophy/no-word-attachments.html
> > > > ----------------------------------------------------------------------
> > > > Ott Pattara Kiatisevi T L W G
> > > > M.Sc. INFOTECH Student, Stuttgart, Germany http://linux.thai.net/
> > > > ----------------------------------------------------------------------
> > >
> > > --
> > > Joel Sherrill, Ph.D. Director of Research & Development
> > > joel at OARcorp.com On-Line Applications Research
> > > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > > Support Available (256) 722-9985
> > >
> > >
> >
> >
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list