-1
$\begingroup$

Suppose there are three threads A, B, C and thread A has acquired a mutex lock and it is processing. If threads B and C try to acquire the same mutex, they will be blocked according to the mutex lock concept. But once thread A completes, which of the threads will be unblocked? Is there any scheduling policy?

$\endgroup$
2
  • 1
    $\begingroup$ What have you tried? Where did you get stuck? We do not want to just do your (home-)work for you; we want you to gain understanding. However, as it is we do not know what your underlying problem is, so we can not begin to help. See here for a relevant discussion. If you are uncertain how to improve your question, why not ask around in Computer Science Chat? You may also want to check out our reference questions. $\endgroup$
    – Raphael
    Commented Mar 16, 2016 at 10:51
  • $\begingroup$ This question was migrated from unix.se, so it is not worded as we would normally expect a cs.se question to be worded. $\endgroup$
    – Pseudonym
    Commented Mar 16, 2016 at 22:48

1 Answer 1

4
$\begingroup$

The short answer is "it depends".

If there is truly nothing to distinguish thread B from thread C, then the answer on most scheduler implementations will likely be either "could be B or C, and you can't predict which one in advance", or "the one which tried to acquire the mutex first" (i.e. first-come, first-served).

However, there may be something which distinguishes them in some way, and that's where it gets more interesting. In particular, if the implementation supports priority scheduling, one of the threads may have a higher priority than the other, in which case the higher-priority thread should be scheduled first.

Sometimes the programmer will decide that thread B should have a higher priority than thread C. Some schedulers assign higher priorities to tasks which have earlier deadlines, or periodic tasks with shorter periods (known as rate-monotonic scheduling).

In other circumstances, even if two threads have the same nominal priority, the scheduler may give one a higher effective priority than the other.

For example, in a non-realtime system, a scheduler may decide that one thread is more of a background task than the other (e.g. in a pre-emptive multitasking environment, a thread which seems to exhaust its quantum is probably a "background thread"), and so should have a lower effective priority than a more "interactive" thread. This is a common heuristic to make a system more responsive (or appear more responsive!) because interactive jobs are given priority.

Another common scenario is if one of the threads is already holding a priority-aware synchronisation object (say, a priority inheritance mutex or a priority ceiling mutex). In that case, the thread may have its effective priority raised to ensure that it releases the critical object more quickly.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.