This is the mail archive of the
mailing list for the Cygwin project.
Re: Problems with pthread mutexes
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Sat, 25 Sep 2004 22:24:18 -0700
- Subject: Re: Problems with pthread mutexes
- Organization: My own little world...
- References: <BAY9-F5FQG101s7hpJm0000de08@hotmail.com>
- Reply-to: cygwin at cygwin dot com
Arash Partow wrote:
> The result I get back is 16 which according to stderror is: "Mount device
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))
*attr = new pthread_mutexattr ();
if (!pthread_mutexattr::is_good_object (attr))
*attr = NULL;
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html