[Rpm-devel] rpm-4.4.6 on solaris9-sparc64
Tim.Mooney at ndsu.edu
Thu Jun 29 18:19:40 EDT 2006
In regard to: Re: [Rpm-devel] rpm-4.4.6 on solaris9-sparc64, Jeff Johnson...:
> How the mutex is initialized is likely the problem. That issue popped up on
> cygwin, perhaps similar on solaris.
> Specifically, this bit of deep dark chocolate goo may need to be figgered on
> #ifndef PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
> static pthread_mutex_t rpmsigTbl_lock = PTHREAD_MUTEX_INITIALIZER;
> static pthread_mutex_t rpmsigTbl_lock =
> The sq->mutex is initialized dynamically rather than statically, perhaps
> different arg is needed on solaris smp.
> I'll try to dig up more info on posix mutexes before this weekend.
I know next to nothing about pthread programming, and the last time I did
any thread programming was 15 years ago using Solaris 2.3 threads (lwp*
stuff) and I wasn't any good at it then, so I doubt I'm going to be much
help with 15 years of rust.
I'm looking at the code in rpmio/rpmsq.c and looking at the Solaris 10 man
pages for pthread_mutexattr_init, pthread_mutexattr_settype, and
pthread_mutex_init, and the code that's in rpmsq.c seems like it's
following the rules as spelled out in the man page. There is one possibly
interesting note in the pthread_mutexattr_settype(3C) man page regarding
PTHREAD_MUTEX_RECURSIVE. The very last sentence describing that attribute
type of mutex is only sup-
ported for mutexes whose
process shared attribute is
However, doing a bit more research in the pthread_mutexattr_setpshared(3C)
man page says this:
The process-shared attribute is set to
PTHREAD_PROCESS_SHARED to permit a mutex to be operated upon
by any thread that has access to the memory where the mutex
is allocated, even if the mutex is allocated in memory that
is shared by multiple processes. If the process-shared
attribute is PTHREAD_PROCESS_PRIVATE, the mutex will only
be operated upon by threads created within the same process
as the thread that initialized the mutex; if threads of
differing processes attempt to operate on such a mutex, the
behavior is undefined. The default value of the attribute is
So, it sounds like the process-shared attribute should be defaulting
to PTHREAD_PROCESS_PRIVATE, so PTHREAD_MUTEX_RECURSIVE should be legal.
Now that I know where the INIT_LOCK() stuff is, though, I might try adding
return value checks to each step of the macro, to see if something is
returning a useful error.
Tim Mooney mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
More information about the Rpm-devel