13

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?

csss
  • 231
  • 2
  • 5

1 Answers1

28

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.

Blrfl
  • 20,235
  • 2
  • 49
  • 75
  • so in a way it is polling but at OS level? – tgkprog Mar 30 '13 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 Mar 30 '13 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 Mar 31 '13 at 09: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 Mar 31 '13 at 15:00
  • @Blrfl so when the process with the mutex terminates the kernel is notified via an interrupt? I am wondering how the kernel knows that the process has terminated without polling the process/mutex. – csss Apr 01 '13 at 07:55
  • 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 Apr 01 '13 at 11:09