When is pthread_mutex_destroy necessary?

Question

I want to ask the proper usage of pthread_mutex_t.

I understand that you can either initialize by using the pthread_mutex_init function or setting it equal to PTHREAD_MUTEX_INITIALIZERand that pthread_mutex_destroy "destroys" the mutex.

I am wondering about if it is okay not to call pthread_mutex_destroy and in what circumstances it is necessary? I found the specification here: here.

Here is my specific use case:

struct entries; 

struct hash_table {
  struct hash_table_entry entries[HASH_TABLE_CAPACITY];
  pthread_mutex_t fine_grain[HASH_TABLE_CAPACITY];
};

struct hash_table *hash_table_create() {
  struct hash_table *hash_table = calloc(1, sizeof(struct hash_table));
  for (size_t i = 0; i < HASH_TABLE_CAPACITY; ++i) {
  ...
  hash_table->fine_grain[i] = PTHREAD_MUTEX_INITIALIZER;
}
  return hash-table
}

The reason I ask is that the teaching assistant in charge of the project has stated:

After using a lock, make sure you will destroy it, we will check for memory leaks

This is not referencing the allocated hash table, but the individual locks, so I am wondering why pthread_mutex_destroy might ever be necessary.

Answer 1

if it is okay not to call pthread_mutex_destroy and in what circumstances it is necessary?

I do not want memory leaks.

If you have just a variable pthread_mutex_t a = PTHREAD_MUTEX_INITIALIZER; and you do nothing with it then calling pthread_mutex_destroy is not necessary.

If you call pthread_mutex_lock(&a) on it, the lock function can potentially allocate memory or other resources. In such case, you should call pthread_mutex_destroy(&a) to make sure the implementation frees that memory.

But yes - there may and do exist implementations that do not allocate memory for mutexes. This it not a restriction, there may exist implementations that do allocate memory for mutexes upon calling _lock(), so to not have any leaks on such implementatin you should call _destroy().

The POSIX specification you linked has a whole section discussing static initialization for mutexes. Newer version is available at https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html . In particular, it mentions:

Yet the locking performance question is likely to be raised for machines that require mutexes to be allocated out of special memory. Such machines actually have to have mutexes and possibly condition variables contain pointers to the actual hardware locks. For static initialization to work on such machines, pthread_mutex_lock() also has to test whether or not the pointer to the actual lock has been allocated. If it has not, pthread_mutex_lock() has to initialize it before use. The reservation of such resources can be made when the program is loaded, and hence return codes have not been added to mutex locking and condition variable waiting to indicate failure to complete initialization.

This runtime test in pthread_mutex_lock() would at first seem to be extra work; an extra test is required to see whether the pointer has been initialized. On most machines this would actually be implemented as a fetch of the pointer, testing the pointer against zero, and then using the pointer if it has already been initialized. While the test might seem to add extra work, the extra effort of testing a register is usually negligible since no extra memory references are actually done. As more and more machines provide caches, the real expenses are memory references, not instructions executed.

Answer 2

TLDR:

Pedantically, you need to call pthread_mutex_destroy() for every initialized mutex if you need to be absolutely certain no resources are leaked under any circumstances.

In reality, most times it won't matter, either because there's no way to call pthread_mutex_destroy(), or you know your implementation doesn't use dynamic memory in mutexes, or the process is exiting and you don't really care if it leaks.

Full Answer:

To expand on @KamilCuk's answer, from his link to POSIX's documentation for pthread_mutex_destroy():

An implementation may cause pthread_mutex_destroy() to set the object referenced by mutex to an invalid value.

One way to do that is for an implementation to call free() for mutex resources allocated during the creation and use of the mutex. Nothing rules out an implementation using dynamic allocation for any mutex - an implementation is even free under the "as-if" rules of C's abstract machine to use a PTHREAD_MUTEX_INITIALIZER that performs dynamic allocation even for static initialization of static variables at file scope, where normally C would not allow something like

static some_type *var = malloc( sizeof( *var ) );

(If C++ can create new objects at file scope, it'd be almost trivial for a C implementation to use something similar internally, even if it flags your attempts to do so as C errors.)

So pedantically, if you want to strictly avoid leaking any memory, pthread_mutex_destroy() must be called for every mutex you initialize.

The reality is different.

First, many (most?) of the time you will use a mutex, there will be no easy way to destroy it. For example, it can be a static with limited scope deep inside a function used to protect a critical section of code - there's no way to reliably call pthread_mutex_destroy() on such a mutex. Even if you register an atexit() function to destroy the mutex, that function won't be called in all ways a process can exit.

Second, most implementation of standard mutexes don't allocate any dynamic memory.

Third, many (most?) uses of mutexes are meant to exist for the life of the program - they only need to be destroyed if the program is exiting. And if the program is exiting, there's no functional impact if they're not destroyed.

But if you're creating structs dynamically and initializing mutexes in the structs with pthread_mutex_init(), you really should run pthread_mutex_destroy() on them when you free() the struct even if you know your use of your implementation's mutex doesn't do any dynamic allocation - someone might change the mutex to something more complex like an error-checking or robust mutex that might very well dynamically allocate memory on your implemenation, the code could be ported to another implementation, or the implementation itself could change. Get it right and don't open up that window for a completely unnecessary future bug.