delorie.com/archives/browse.cgi | search |
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> |
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/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |