This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with pthread mutexes

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

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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]