unix/linux套接字中的阻塞模式如何工作? [英] How does blocking mode in unix/linux sockets works?

问题描述

阻塞模式是否将特定任务置于进程等待"状态，因为我认为非阻塞套接字需要明确地从用户那里实现忙等待"或自旋锁定"实现.或阻塞模式套接字不过是内核忙等待的隐式实现.

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.

推荐答案

基于我从net/book/中学到的知识并提供了答案.我会尽力而为.

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

默认情况下，所有套接字都处于阻塞状态.这意味着，当我们发出无法立即完成的套接字调用时，我们的进程将进入睡眠状态，等待条件发生. unp-p435

通过将进程置于等待/阻塞状态来实现睡眠.调度程序在被阻止的进程打开时(即，调度程序将CPU交给他时)检查条件以解除阻止该进程.在这种情况下，响应速度取决于调度程序的时间分辨率.

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.

这篇关于unix/linux套接字中的阻塞模式如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！