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

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.