init and destroy of mutexattr

Greetings all,

A question regarding pthread_mutexattr_init() and pthread_mutexattr_destroy().

I understand that one uses …init() to create an mutex attribute, and that …destroy() destroys the mutex attribute.

But is the destroy really necessary? I’ve seen utility code in my work base where a function is called multiple times and they invoke the init() function each time, to create a new mutex, but they don’t invoke destroy() on the attribute.

How grouchy should I get with my co-workers about this?

I am concerned because one of the return values from init() is ENOMEM which makes me think that the mutex attr is an opaque structure that dynamically allocates some memory, attaching it to the attr.

Which would then imply we have a memory leak as they init but don’t destroy.

Any advice, or comments?

Thanks all.

-=John

John,

You should be all over them about this.

It’s not a memory leak that this is causing but a resources leak. The resource being leaked is Kernal mutexes. Eventually if the code runs long enough it will use up all the mutexes in the system.

What they are doing is equivlent to opening a file and never closing it. Eventually you’ll run out of file descriptors.

BTW, I don’t see an ENOMEM return from the init() call. The EAGAIN is the one that gets returned when the kernal runs out of mutexes.

Tim

Are you sure Tim, this is the attribute and not the mutex itself. The same attribute can be use to init multiple mutexes.

I just looked at the source code and pthread_mutexattr_destroy does nothing!!! It return EOK. That being said I think it’s still good practice to have a destroy() for each attribute that get initialize. John It may actually be required as per POSIX specification. Some implementation of the init may allocated resources that needs to be freed. That is currently not the case under Neutrino 6 but that would be a mistake to assume so.

Hum seems I was wrong. I just check the POSIX spec ( from 2004) and it seems calling pthread_mutexattr_destroy is not a requirement.

Steve are you reading this, maybe some clarification on the issue is needed?

Mario,

D’oh! I misread the initial post as pthread_mutex_init().

You are right I don’t think you need to destroy the attrinit() call since it’s clearly empty code as you found out. Though I agree it makes sense in principal to do so since it’s obviously a Posix convenience function for an underlying O/S call to take place to free resources if needed.

Tim

Yes, you’re right: POSIX seems more concerned with not reusing a destroyed mutex than destroying a mutex when you’re done with it (although cleaning up after yourself sounds like a good practice).

I don’t think the docs should encourage people not to destroy the mutex – someday, our implementation of pthread_mutex_destroy() just might do something!

Thanks all.

So if I understand correctly, this is a good housekeeping habit to develop for now.

It doesn’t cause anything to leak with QNX right now. However, if the code were ported to another platform, or QNX changed its functionality, it could cause a leak. Better safe than sorry.

Thanks again,

-=John