Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: atacama.four-d.de: mail set sender to <tpfaff AT gmx DOT net> using -f
Message-ID: <3F93AFF1.9000102@gmx.net>
Date: Mon, 20 Oct 2003 11:50:41 +0200
From: Thomas Pfaff <tpfaff AT gmx DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joost Kraaijeveld <J DOT Kraaijeveld AT askesis DOT nl>
CC: cygwin <cygwin AT cygwin DOT com>
Subject: Re: Problems with phread_mutexattr_init
References: <A3D1526C98B7C1409A687E0943EAC41015E307 AT obelix DOT askesis DOT nl>
In-Reply-To: <A3D1526C98B7C1409A687E0943EAC41015E307@obelix.askesis.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/