Say we have some thread that wants to check when another thread is finished its task. I have read that we should call a wait() type function that will make this thread wait until it receives a notification that the other thread is finished. And that this is good because it means we aren't performing expensive polling.

But isn't polling happening internally at a lower level anyway? I.e. if we make the thread wait() isn't the kernal performing polling anyway to check when the other thread is finished so that it can then notify the first thread?

I presume I a missing out on something here, can someone enlighten me?

1 Answer 1


The operating system provides certain primitives for this kind of interprocess communication that don't require polling.

If process A is waiting on mutex M, the OS knows A can't be run and puts it aside in a bucket of processes waiting for something to happen. When the process holding M releases it, the OS looks at the list of processes waiting for it. The first process on the list, maybe A, gets removed from the idle bucket and put on the run queue. The next time A gets a time slice, the wait() it called will return and the program continues.

  • so in a way it is polling but at OS level?
    – tgkprog
    Commented Mar 30, 2013 at 22:01
  • 7
    No @tgkprog, this is not polling, because the waiting process is not scheduled to run until the OS or another process releases the mutex. A polling process would continue to compete in cpu scheduling in order to check whether it should stop waiting. A polling process of this sort can burn a substantial portion of CPU time while it waits.
    – joshp
    Commented Mar 30, 2013 at 23:25
  • i meant the OS process polling the mutex status. though i'm sure its optimized and better than anything we could do. probably runs as part of the scheduler.
    – tgkprog
    Commented Mar 31, 2013 at 9:34
  • 4
    @tgkprog: The OS doesn't pay a bit of attention to what's going on with a mutex until the process holding it releases it or terminates. Either of those events will cause the OS hand the mutex lock to whatever process is first on the waiting list and mark that process as runnable. There's no polling involved, just response to an event. Everything joshp said is included by reference. :-)
    – Blrfl
    Commented Mar 31, 2013 at 15:00
  • 2
    @csss: Pretty much. Processes may terminate voluntarily (e.g., calling _exit(2) on POSIX-y systems) or involuntarily (e.g., an error like a divide-by-zero generates an interrupt or something else calls kill(2)). In either case, control is explicitly handed back to the OS, which knows what process was running or is to be killed. The job of ending a process includes freeing its resources, mutexes included. If a mutex was held by the now-dead process, the OS will release it. If the process was on the mutex's waiting list, it will be removed.
    – Blrfl
    Commented Apr 1, 2013 at 11:09

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.