How does blocking mode in unix/linux sockets works?

Question

Does blocking mode put that particular task in a "Process Wait" state, as i think non-blocking sockets needs a "busy-wait" or "spin-lock" implementation, explicitly from the user. Or blocking mode sockets are nothing but implicit-implementations of busy-wait by the kernel.

In locking mechanisms like semaphores/mutexes/monitors a lock is usually achieved by pushing the task in Blocked State. I think if such things are possible with locking, then socket locking might also be achieved by same way.

I dont know for sure, I think polling is not a efficient way, esp for the kernel, as the kernel always has his hands full with so many tasks.

thx.

Answer 1

No, blocking sockets are implemented in the kernel. The process is into a non-executing state, and does not consume any CPU time.

The kernel is free to run other tasks until some outside activity would cause it to wake the task up. For instance, a hardware interrupt for the network card letting it know there is data to be read. The kernel reads it and pushes it through the network stack, eventually waking up the application to process the data.

Timers would work the same way, but with the timer interrupt.

The kernel might actually be polling hardware under the hood, but it doesn't have to be... that's all a matter of how the hardware is designed.

Answer 2

Please see my answer to this question: C++ - how does Sleep() and cin work?

Answer 3

Based on what i learnt from net/book/ and provided answers. I will try to be to the point.

By default all sockets are blocking. This means that when we issues a socket call that cannot be completed immediately, our process is put to sleep, waiting for the condition to be ture. unp -- p435

Sleep is implemented by putting the process in the wait/blocked state. Scheduler checks for the condition to un-block the process, when the blocked process get it turn, ie when the scheduler give him the CPU. The responsiveness in this case depends on the time resolution of the scheduler.

So, the blocking calls are not implicit implementation of "busy wait" or "spin lock" from the kernel.

Yes underlying mechanism of locking is same for most of the implementations. Putting process to blocked/wait state.

Of-course polling was not efficient, ie why blocking is not implemented using polling.