0

I have a problem understanding mutex, For example let's consider the following code from my book:

int students[2] = {0};
cond_t conds[2];
mutex_t global;
void onArrival(int faculty) {
    mutex_lock(&global);
    int other = facolty ? 0:1;
    while(students[other]>0) cond_wait(&conds[facolty],&global);
    students[facolty]++;
    mutex_unlock(&global);
}
void onLeave(int faculty) {
    mutex_lock(&global);
    students[facolty]--;
    int other = facolty ? 0:1;
    cond_broadcast(&conds[other]);
    mutex_unlock(&global);
}

enter image description here

cond_broadcast will wake up all waiting threads but the real question is for how long? I mean it may happen that line 16 was executed which woke up 1000 threads but when they try to catch the mutex they fail because line 17 wasn't executed yet...

So what will happen in this case?

Threads go back to sleep and when doing line 17 none will wake up?

Or, They will do busy waiting until the mutex in released?

algo
  • 101
  • 6
  • 1
    Please, do NOT use *images* of **code**. Instead, paste the code into the question post as **text**, formatting it appropriately. This is how Stack Overflow works. See also [ask]. – Tsyvarev Oct 11 '21 at 10:16
  • @Tsyvarev Done, Can you help me now? – algo Oct 11 '21 at 10:48
  • Does this answer your question? [Which thread owns the associated mutex after pthread\_cond\_broadcast?](https://stackoverflow.com/questions/34846498/which-thread-owns-the-associated-mutex-after-pthread-cond-broadcast) – Tsyvarev Oct 11 '21 at 11:17
  • `cond_broadcast` turns waiters threads into the state, similar to one at `mutex_lock` call. That is, if the mutex is locked, then all waiters remains in a waiting state, but that time they will wait for the *mutex*, not for the *condition*. – Tsyvarev Oct 11 '21 at 11:20

1 Answers1

0

cond_broadcast will wake up all waiting threads but the real question is for how long? I mean it may happen that line 16 was executed which woke up 1000 threads

Yes, in the sense that it transitions them from waiting on the CV to contending for the mutex. They may or may not actually become eligible for scheduling or receive any CPU time before they succeed in acquiring the mutex (thanks to @DavidSchwartz for this clarification).

but when they try to catch the mutex they fail because line 17 wasn't executed yet...

No. The threads do not fail to acquire the mutex, at least not for that reason. They just may have to wait before they do acquire it.

So what will happen in this case?

Threads go back to sleep and when doing line 17 none will wake up?

Or, They will do busy waiting until the mutex in released?

It depends on the implementation of the mutex, but generally, threads attempting to acquire a mutex block until they can do so. They do not wait busily. It is exactly the same whether they are explicitly acquiring the mutex or whether they are acquiring it after being aroused from a wait on a CV.

Note well that any threads that do block trying to acquire the mutex are not in the same state as when they were awaiting a signal from the CV. They are in contention for the mutex whereas they were not before, and they do not need another signal from the CV before proceeding.

This is a somewhat astute question, because there is indeed a real-life performance consideration here. With a CV implementation that allows signaling or broadcasting to a CV without holding the associated mutex locked, such as pthreads, it can be more efficient to do it with the mutex unlocked, so that at least one thread can proceed right away instead of waking and then immediately blocking again. But that's an efficiency issue, not a semantics issue.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157