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: <3EE70741.8070405@gmx.net>
Date: Wed, 11 Jun 2003 12:41:05 +0200
From: Thomas Pfaff <tpfaff AT gmx DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rasmus Hahn <rassahah AT neofonie DOT de>
CC: cygwin <cygwin AT cygwin DOT com>
Subject: Re: Problem w/ c++,threads,static initializers
References: <20030607142449 DOT A4909 AT hamburg DOT neofonie DOT local> <3EE587F7 DOT 9090405 AT gmx DOT net> <20030611080702 DOT A1768 AT hamburg DOT neofonie DOT local> <3EE6CF20 DOT 7070005 AT gmx DOT net> <20030611120551 DOT A3205 AT hamburg DOT neofonie DOT local>
In-Reply-To: <20030611120551.A3205@hamburg.neofonie.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Rasmus Hahn wrote:
> Hi Thomas,
> 
> Problem solved: it was not the mutex but the but the pthread_mutexattr_t
> that caused the error. cygwin's pthread_mutexattr_init () function checks
> if its argument points to a valid object. If the pthread_mutexattr_t's 
> value still points to a valid object (from a previous call)
> pthread_mutexattr_init () fails, and so do later pthread_mutex_init()s with
> this attribute. I think this behaviour is not correct since an uninitialized
> pthread_mutexattr_t can point to anything (as a previously created attribute),
> so this is probably a bug in cygwin (or what does the International Pthread
> Attributes Committee say?). A quick look in winsup/cygwin/thread.cc shows
> that this kind of check is done for more of the ..._init() functions, so there
> may be similar effects (but i did not test that yet). Demo-Program below does
> not work with (my) cygwin but does in my linux box:
> 
> #include <pthread.h>
> int main () {
>   pthread_mutexattr_t attr;
>   pthread_mutexattr_init (&attr);
>   if (pthread_mutexattr_init (&attr)) {
>     printf ("error should not happen\n");
>   }
> }
> 

Have a look at
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutexattr_init.html 


"Results are undefined if pthread_mutexattr_init() is called specifying 
an already initialized attr attributes object."

Unfortunately the spec does not specify EBUSY (which as returned at the 
moment) as a valid return code for pthread_mutexattr_init, therefore i 
will change all attr_init functions to simply return 0 if they are 
called with an already initialized attribute.

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/