delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/09/26/01:22:04

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
Message-ID: <41565282.E62D54E9@dessent.net>
Date: Sat, 25 Sep 2004 22:24:18 -0700
From: Brian Dessent <brian AT dessent DOT net>
Organization: My own little world...
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Problems with pthread mutexes
References: <BAY9-F5FQG101s7hpJm0000de08 AT hotmail DOT com>
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

Arash Partow wrote:

> The result I get back is 16 which according to stderror is: "Mount device
> busy".

That would be EBUSY.

> The mutex is being created within a running thread. It is very strange
> that the same code compiles fine on other OS and that they don't give
> back an error.
> 
> I'll try writing up a more simpler example that can be run,
> also I'm compiling with -O3,I'm not sure how cygwin's modes
> to gcc effect this level of optimization.

Here's the code in question, in thread.cc:

pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
  if (pthread_mutexattr::is_good_object (attr))
    return EBUSY;

  *attr = new pthread_mutexattr ();
  if (!pthread_mutexattr::is_good_object (attr))
    {
      delete (*attr);
      *attr = NULL;
      return ENOMEM;
    }
  return 0;
}

The first check there is a little odd - essentially it's checking the
as-yet uninitialized pthread_mutexattr_t object to see if it happens to
contain the value PTHREAD_MUTEXATTR_MAGIC, which would indicate that it
has already been initialized.  I guess that's to prevent memory leaks
from accidental calling of pthread_mutexattr_init() twice on an object
without calling pthread_mutexattr_destroy() first.  So, check and see if
there's any possibility of that happening in your code.

But, since your pthread_mutexattr_t is being allocated on the stack I
suppose there's a chance that it might happen to contain the magic value
from a previous function.  You could try bzero()-ing it if you're sure
that it's uninitialized (and that it's not a case of trying to init the
same structure twice) and that should make the error go away.  But, I'm
certainly no Cygwin pthread expert so maybe someone else can eludicate
us on the use of the magic numbers and verifiable_object usage.

I don't know how the use of -O3 affects initialization of automatic
variables, but if bzero()-like behavior is normally done but disabled at
that level, then it would definitely be the culpret.

Brian

--
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019