c++ correct use of mutex

Question

i have multithreaded project and i've run it through valgrind with --tool=helgrind and it showed me few errors. I'm using mutex there exaxtly how i found on the net how to use it, can you please show me whats wrong?

#include <iostream>
#include <pthread.h>

#define MAX_THREADS     100
#define MAX_SESSIONS    100

static pthread_mutex_t  M_CREATE_SESSION_LOCK= PTHREAD_MUTEX_INITIALIZER;


.....



void connection::proccess(threadVarsType &THREAD) {
    ....

    pthread_mutex_lock(&M_CREATE_SESSION_LOCK);

    unsigned int ii;
    for (ii=0; ii<MAX_SESSIONS; ii++) {
        if (SESSION[ii]==NULL) {
            break;
        }
    }
    if (ii==MAX_SESSIONS-1) {
        ....
        pthread_mutex_unlock(&M_CREATE_SESSION_LOCK);                       // unlock session mutex
        ....
        return;
    } else {
        ....
        pthread_mutex_unlock(&M_CREATE_SESSION_LOCK);                       // unlock session mutex
        ....
    }

    ....
}

and the error messages:

==4985== Thread #1's call to pthread_mutex_lock failed
==4985==    with error code 22 (EINVAL: Invalid argument)
    ....
==4985== Thread #1 unlocked an invalid lock at 0x4E7B40
==4985==    at 0x32CD8: pthread_mutex_unlock (hg_intercepts.c:610)
    ....
==4985== Thread #1's call to pthread_mutex_unlock failed
==4985==    with error code 22 (EINVAL: Invalid argument)
    ....
==4985== Thread #1's call to pthread_mutex_lock failed
==4985==    with error code 22 (EINVAL: Invalid argument)
    ....
==4985== Thread #1 unlocked an invalid lock at 0x4E7B40
==4985==    at 0x32CD8: pthread_mutex_unlock (hg_intercepts.c:610)
    ....
==4985== Thread #1's call to pthread_mutex_unlock failed
==4985==    with error code 22 (EINVAL: Invalid argument)

Answer 1

First, always check the return values of your function calls. If a pthread call fails, it's a good choice to just call abort() which will core-dump if you have that enabled or drop into the debugger if you are running with one.

The pthread function calls really should never fail, which means that something is seriously wrong with your program. In a C or C++ program something that commonly causes mysterious failures is memory corruption. Use valgrind in its normal modes to check for that.

Another thing that can cause pthread calls to fail is to not compile using -pthread. If using GCC you should compile and link using gcc with a command like gcc -pthread. That will link the pthread library and it will set some preprocessor defines that may be important for your system's header files.

Some systems will successfully compile and link a program that is using pthread calls without linking it to the pthread libraries. This is done so that a program or library can be made thread-safe without actually using threads. The thread calls will be linked to dummy functions unless the real pthread library is linked. That can lead to some function calls failing.

So make sure you are building with the correct compiler options to include the pthread libraries.

Another possible cause is if you are building on some whacked-out half-and-half hybrid OS where it started as Linux 2.4 and got upgraded to Linux 2.6 NPTL at some point (I worked on something like this once). If you are attempting to compile against old header files with an outdated definition of PTHREAD_MUTEX_INITIALIZER or the wrong size for the type of pthread_mutex_t then that could cause the problem.

Answer 2

That error suggests something is wrong with the initialization of the mutex. It's hard to way what, but make sure you're initializing it in the right place.

Answer 3

On the Helgrind docs page, they mention that there could be false positives that are suppose to be suppressed ... somehow you might be bumping into those since on the surface it does not seem like you're using pthread mutexes incorrectly.

Here's what they write:

Helgrind's error checks do not work properly inside the system threading library itself (libpthread.so), and it usually observes large numbers of (false) errors in there. Valgrind's suppression system then filters these out, so you should not see them.

If you see any race errors reported where libpthread.so or ld.so is the object associated with the innermost stack frame, please file a bug report at http://www.valgrind.org/.

They also note that you should be using a "supported Linux distribution" ... they don't mention what exactly that means, but if you're using a non-Linux OS, that could also possibly cause some of these "false positives". It might be worth asking the development team to see what they say about this.

Answer 4

The error EINVAL on a call to pthread_mutex_lock means one of two things.

The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling.

or

The value specified by mutex does not refer to an initialised mutex object.

The second one seems more likely. Try initializing the mutex in your main function with int error = pthread_mutex_init(&M_CREATE_SESSION_LOCK, NULL); and check if there is an error, instead of initializing it with the macro like you are currently.