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();
}