Pthread_mutex_lock

Question

Hello-
I'm using the pthread library on a Solaris 8 machine. The problem is when I perform a pthread_mutex_lock on a mutex that has been initialized with the PTHREAD_PRIORITY_INHERIT protocol form a pthread that has been created with scheduling attributes other than the default, I get an error (EPERM). The error only occurs when I'm a user other that root, as root it runs fine. Does anyone have any insight into this? Below is some test code that results in an error when I'm not root.
Thanks
#define POSIXSOURCE
#define POSIXC_SOURCE 199309
#include <stdio.h>
#include <sys/types.h>
#include <errno.h>
#include <fcntl.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
#include <ucontext.h>
#include <pthread.h>
#include <sched.h>
#include "vmeintr.h"
void test();
void threadTest();
pthread_mutex_t testMutex;
* Function:     main- system's boardMain function
int main(void) {
int status;
struct sched_param priority_param;
pthread_attr_t thread_attr;
pthread_attr_init(&thread_attr);
pthread_attr_setinheritsched(&thread_attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&thread_attr, SCHED_RR);
int fifo_max_prio = sched_get_priority_max(SCHED_RR);
int fifo_min_prio = sched_get_priority_min(SCHED_RR);
priority_param.sched_priority = ((fifo_max_prio+fifo_min_prio)/2);
pthread_attr_setschedparam(&thread_attr, &priority_param);
pthread_t testThread;
if( pthread_create(&testThread,
          &thread_attr,
          (void * (*)(void *))threadTest,
          NULL) != 0) {
fprintf (stderr,"(%s):%d Initialization thread could not be created, exiting!\n",__FILE__, __LINE__);
if(pthread_join(testThread, NULL) != 0) {
fprintf(stderr, "Thread could not be joined! \n");
test();
while(1){};
exit(0);
void test() {
int status = pthread_mutex_lock(&testMutex);
if(status != 0) {
fprintf(stderr,"%s:(%d) Mutex lock error %d.\n",__FILE__,__LINE__,status);
fprintf(stderr,"%s:(%d) This is what we locked %d.\n",__FILE__,__LINE__,status);
status = pthread_mutex_unlock(&testMutex);
if(status != 0) {
fprintf(stderr,"%s:(%d) Mutex unlock error %d.\n",__FILE__,__LINE__,status);
void threadTest() {
pthread_mutexattr_t mutexAttr;
int mutex_protocol;
int status;
#ifdef POSIXTHREAD_PRIO_INHERIT
fprintf(stderr,"%s(%d): _POSIX_THREAD_PRIO_INHERIT is defined. \n",__FILE__,__LINE__);
#endif
pthread_mutexattr_init(&mutexAttr);
int fifo_max_prio = sched_get_priority_max(SCHED_RR);
if(pthread_mutexattr_setprotocol(&mutexAttr,PTHREAD_PRIO_INHERIT) != 0) {
fprintf(stderr,"%s(%d): pthread_mutexattr_setprotocol failed. \n",__FILE__,__LINE__);
status = pthread_mutex_init(&testMutex, &mutexAttr);
if(status != 0) {
fprintf(stderr,"%s:(%d) mutex_init error %d.\n",__FILE__,__LINE__,status);
test();

Answer 1

Hi,
I have never used priority inheritence, I have forgotten everything about PTHREADS that I did know, and I am replying a month late, so I am effectively useless.
One thing I wanted to suggest is that you try BOTH pthread libraries on Solaris 8. The alternative threading library (which is a backport of the Solaris 9 1:1 threading library) might behave a little differently. Here is a snippet from a doc (http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf):
Two Libsthread
The old threads implementation resided in /usr/lib:
/usr/lib/libthread.so.1 (32-bit)
/usr/lib/sparcv9/libthread.so.1 (64-bit)
The new implementation was in /usr/lib/lwp:
/usr/lib/lwp/libthread.so.1 (32-bit)
/usr/lib/lwp/sparcv9/libthread.so.1 (64-bit)
The Pthreads filter library (libpthread) used whichever libthread was selected, and so remained in
/usr/lib:
/usr/lib/libpthread.so.1 (32-bit)
/usr/lib/sparcv9/libpthread.so.1 (64-bit)
To select the alternate libthread at runtime, dynamic linker search path could be set as follows:
LD_LIBRARY_PATH=/usr/lib/lwp (32-bit)
LD_LIBRARY_PATH_64=/usr/lib/lwp/sparcv9 (64-bit)
To build a binary that would default to the alternate libthread, specify a runpath at link time:
cc -mt ... -R /usr/lib/lwp (32-bit)
cc -mt ... -R /usr/lib/lwp/sparcv9 (64-bit)
Fuller details can be found in the threads(3THR) manpage.
I do hope this helps.
jonnie savell