This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with phread_mutexattr_init


Joost Kraaijeveld wrote:
Hi Thomas,

Sorry for contacting you outside the Cgwin mailing list directly but I
am really desperate for an answer. I searched the mailinglist, Googled,
read the IEEE specs, studied several PThread implementations, actually
ran the code on BSD, Linus, Solaris and Cygwin but still have no answer
for my problem (now I hope you are convinced that I tried to find a
sollution but that I did not find any ;-)).

Can you explain to me under what circumstances pthread_mutexattr_init
returns EBUSY? I read the explanations in
http://sources.redhat.com/ml/cygwin/2003-06/msg00431.html and
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutexatt
r_init.html and from that I understand that  pthread_mutexattr_init
returns EBUSY if one tries to initialize twice. However I sometimes (not
always) get the error in the following part of  code (see below & the
arrows on the left). The initialization is done only once. As far as I
can see it is not the constructor of a static object called twice bu 2
threads. (The debugger does not give me enough stacktrace between
signals to make any sence).

Note:

If I initialize pthread_mutexattr_t m_attr with 0 (because it's actually
a pointer to a struct according to <sys/types>) the code runs OK. This
looks strange to me. Why should I have to initialize a
pthread_mutexattr_t by any other means than by calling
pthread_mutexattr_init ?

MICOMT::Mutex::Mutex(MICO_Boolean locked, Attribute attr)
{
int result;
pthread_mutexattr_t m_attr /* = 0 */; <-----
--> result = pthread_mutexattr_init(&m_attr);
--> assert(!result); if (attr != Normal) {
switch (attr) {
case Recursive:
result =
pthread_mutexattr_settype(&m_attr,PTHREAD_MUTEX_RECURSIVE);
assert (!result);
break;
default:
break;
}
}
result = pthread_mutex_init(&_mutex, &m_attr);
assert(!result);
result = pthread_mutexattr_destroy(&m_attr); assert(!result);
if (locked)
this->lock();
}



This was discussed some time ago: See http://cygwin.com/ml/cygwin/2003-06/msg00431.html


The problem is that cygwin contains some code to check for an already initialized mutex attr. If the local attr on the stack points to an already initialized mutex attr mutexattr_init will fail. To avoid this make sure that you always destroy a mutex attr when it is not longer needed. This will additionally free some memory which is used internally.

To avoid this problem when you are sure that your mutex attr is not initialized use memset (&m_attr, 0, sizeof(m_attr)) instead of pthread_mutexattr_t m_attr = 0;. The memset code is portable.

Thomas



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]