1

In an already running old code, i have found a place where they were trying to unlock an already unlocked mutex.

I am clear that unlocking an already unlocked mutex will lead to undefined behaviour.

But my doubts are

  1. Am I able to predict the behaviour by checking the compiler documentation?
  2. Is there any chances that it may lead to blocking of the thread (deadlock)?
  3. Undefined behaviour will be seen on the pthread_mutex_unlock where it was unlocking the already unlocked thread? Or the undefined behaviour can be seen on any of the next pthread calls ?
alk
  • 69,737
  • 10
  • 105
  • 255
kalai selvan
  • 53
  • 1
  • 4
  • What have you tried so far? Please post the code that you have come up with so far and explain what you are having difficulty with. – haneefmubarak Nov 05 '14 at 04:22
  • 5
    Undefined behaviour is *undefined behaviour*, anything may happens *after* (not just when) the call which leads to undefined behaviour is made, and I suppose that if it meddle with the process state, it may have effects on any thread of execution, not just the one which made the call. – didierc Nov 05 '14 at 04:53
  • @haneefmubarak. We had an issue that the thread took a lot of time to accomplish its task. Unfortunately we don't have any trace when the issue has occurred. I found this bug while surfing the code. I am trying to correlate the issue with this undefined behaviour. – kalai selvan Nov 05 '14 at 06:29
  • @didierc: thanks. But is the undefined behaviour will happening on every iteration? Since we can't able to simulate the issue. Or will the compiler has specific implementation for the undefined behaviour? – kalai selvan Nov 05 '14 at 06:33
  • Once your program encounters a instruction yelding undefined behaviour, it enters a state where *anything* can happen, per the C language standard definition. Whether it execute that instruction once or an infinity of time doesn't matter: it is already in that state after one execution. Yes, specific implementations may define a behaviour for specific instructions which the C language standard didn't specify behaviour for. In some situations, it may even make sense to expect a certain result. – didierc Nov 05 '14 at 06:40
  • see https://en.wikipedia.org/wiki/Undefined_behavior – didierc Nov 05 '14 at 06:44
  • https://stackoverflow.com/questions/1778780/if-you-unlock-an-already-unlocked-mutex-is-the-behavior-undefined?rq=1 – didierc Nov 05 '14 at 06:47
  • 1
    @didierc Remember that this is jsut true, as far the compiler documention doesn't state different for his circumstances. Because this is what he did ask for too. But excepting that, I totaly aggree. – dhein Nov 05 '14 at 07:22

1 Answers1

1

Am I able to predict the behaviour by checking the compiler documentation?

If the compiler says what the behavior will be, then if you use that compiler (and it retains that behavior) then you can rely on that behavior.

Is there any chances that it may lead to blocking of the thread (deadlock)?

Yes. UB can lead to anything. If, for example, the unlock function unconditionally decrements a lock count, it could underflow, keeping the mutex locked forever.

Undefined behaviour will be seen on the pthread_mutex_unlock where it was unlocking the already unlocked thread? Or the undefined behaviour can be seen on any of the next pthread calls ?

You are asking how the behavior is defined. It is undefined. Anything can happen at any time after this point, at least as far as the POSIX pthreads standard says. Unless something else specifies what will happen, it can be anything at all and you officially have no right to complain.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278