can mutex hang execution?

Question

I am fairly new to using mutexes seriously.

After implementing a few mutexes in various places, I realized that program execution hangs (not exit). I tried to debug it (in eclipse environment) but I couldn't reach a definite reason(or at least i don't know how to find one) However, I know now the program hangs when it tries to make a lock after a few iterations that makes a lock in the same place successfully.

here are some code:

void xxx::receiveModule(timeslice now)
{
    //check if you have received anything in the incoming buffer
    if(!isIncomingDirty())// <- has a mutex inside
        {
            return;
        }
//...
}


bool &yyy::isIncomingDirty() {
    boost::unique_lock< boost::shared_mutex > lock(*Communicator_Mutexes[2]));//<-this will cause hang after a few calls
    return incomingIsDirty;
    }

I dont know what behaviour a deadlock will show when it occurs. 1-is this a deadlock?

2-where would you check to look for the cause?

3-can recursive locking or nested locking of the same mutex cause such situation?

and this one may be off topic:

4-I exchange mutexes between classes to be used in their methods by different threads. is this a common practice? is such thing allowed?

thanks you very much for your comments and solutions

A deadlock typically leads to a hang as some or all of the threads/processes/etc can't make any further progress, can't execute. — Alexey Frunze, Apr 16 '13 at 09:59
that is what I am trying to find manually but no luck yet. Any suggestion to find it using- sort of- a monitor or something? — rahman, Apr 16 '13 at 10:25
A deadlock requires at least two mutexes, say A and B, with thread 1 holding A and waiting on B and thread 2 holding B and waiting on A. Any "leaf" mutex (always taken last) or "root" mutex (always taken first) is therefore exempt from deadlocks. Is the snipper shown the only code locking `Communicator_Mutexes[2]`? If so, it's a leaf lock (the `return` statement doesn't lock anything afterwards) and not a cause of deadlocks. — MSalters, Apr 16 '13 at 11:36
Returning a reference to a bool might not be the best way to do it here, as the caller might use the reference without locking on the corresponding mutex. While this might not be the source of a deadlock it still can corrupt the behaviour of the application. — ogni42, Apr 16 '13 at 12:31

score 1 · Answer 1 · answered Apr 23 '13 at 10:46

Thank you everybody for your kind comments. As you see the question is broad and the problem could have been caused by any of the many reasons you stated. For my case, it was recursive locking that caused a deadlock.

One solution was to use boost::recursive_mutex . But why use it when I can opt for the second solution: avoid recursive locking in the first place
That is what I did and hence problem solved.

Thanks again

can mutex hang execution?

1 Answers1