Linux下阻塞与非阻塞IO

    阻塞:顾名思义,就是指在执行设备操作时若不能获得资源则挂起操作,直到满足可操作的条件后再进行操作,被挂起的进程进入休眠状态,被从调度器的运行队列移走,直到等待的条件满足。

     非阻塞:就是反过来,进程在不能进行设备操作时并不挂起,它或者放弃,或者不停的查询,直到可以进行位置。

    技术分享

Socket编程中,阻塞与非阻塞的区别

阻塞:一般的I/O操作可以在新建的流中运用.在服务器回应前它等待客户端发送一个空白的行.当会话结束时,服务器关闭流和客户端socket. 如果在队列中没有请示将会出现什么情况呢?那个方法将会等待一个的到来.这个行为叫阻塞.accept()方法将会阻塞服务器线程直到一个呼叫到来.当5个连接处理完闭之后,服务器退出.任何的在队列中的呼叫将会被取消.

非阻塞:非阻塞套接字是指执行此套接字的网络调用时,不管是否执行成功,都立即返回。比如调用recv()函数读取网络缓冲区中数据,不管是否读到数据都立即返回,而不会一直挂在此函数调用上。在实际Windows网络通信软件开发中,异步非阻塞套接字是用的最多的。平常所说的C/S(客户端/服务器)结构的软件就是异步非阻塞模式的。 
   
      具体机制就是上面所说的,简明扼要的来说可以打个比方:
      你有数个同学来访 <---> 有若干数据需要收取
      (1)你时不时的去门口看看,没有看到你同学的话就回客厅等待,看到同学就接到客厅来 <---> 非阻塞模式,无论收到 数据与否都返回
      (2)你一直在门口等着你同学,接到后才回客厅 <---> 阻塞模式,接收到数据后才返回
 
    使用阻塞怎么了?会带来什么后果?在什么情况之下?对性能有影响么?:
    套接字有两种模式,阻塞模式与非阻塞模式。默认创建的为阻塞模式.
在blocking model 下:
    套接字在IO时阻塞应用程序,就是说控制权不会返回给应用程序,也就是说程序执行到此代码时会卡住。分两种情况,1.send函数时,只有把要发送的数据下传至TCP层,send这句代码才继续向下执行,此时可确认自己的数据已经在网络上传输了2.recv时,只有收到一定数据给应用程序缓冲区时,recv这行代码才会向下执行。如果不想这样做,可以使用多线程,或者选用其他网络IO模型。一般在做服务器程序时,不会使用阻塞套接字,性能低,数据吞吐率也不高。优点是此种模型编写难度较低,可以用来做入门的学习之用。
非阻塞套接字,IO会马上返回.但在send时,如果SOCKET缓冲区已满,会返回错误,使用WSAGetLastError会得到错误码为WSAEWOULDBLOCK,意思是说在一个非阻塞的套接字上,请求没有完成。recv时如果SOCKET缓冲区没有可以读的数据,也会返回WSAEWOULDBLOCK.
 
  Socket 的模式大概分为这么几种:
1、阻塞式的,Socket操作都需要将线程挂起,等待内核完成后才能返回。
如: 调用connect=>进入内核=>Syn包=〉服务器返回SYN ACK 包=〉connect返回。
=〉ACK包发往服务器。
但一般来说,阻塞和非阻塞对于recv来说意义更大。
当在阻塞式的Socket上调用recv时,如果这时网络栈上没有数据给你接收,那么这时线程将
会挂起,直到有报文给你接收才返回。
这样就造成你的应用程序在企图接收数据时候,而网络栈上没有数据的时候就会被锁住。
有什么办法解决这个问题呢? 我们来介绍IO
2、 IO复用, 就是在企图读写数据的时候先询问下是否可读写,如果不能,可以去干别的事情,不会造成死锁。
但是假如我们有大量的连接需要去频繁的查询可读写状态,每次查询都会和内核交互。这样会造成
效率低下。再介绍一种
3、 重叠IO. 就是一次查询多个Socket的状态。不用去来来回回的遍历。
另外,
在windows socket api 中还有一种消息机制,就是把Socket状态通知到窗口。然后用消息去处理。
对于重叠IO, 在windows上还有完成端口模型,他和重叠端口相比,不但能捕捉到IO事件, 而且内核已经替你完成了Socket IO, 比如read事件, 在内核通知你的时候,他已经帮你读好数据了,并放在你指定的缓存中(这里是指在用户态下,事先为每个Socket分配的内存)。
为什么有这么多socket模式呢? 哪个更好呢?
为什么有,我不知道,可能是出于需求吧,
说说哪个更好?
孤立的来说,其实没有哪个更好? 只有哪个更适合你的应用应用环境。
如: 阻塞式的比较简单,方便,稳定。适合比较简单的客户端程序。
IO复用我认为它适合SocketIO操作比较少的情况。
重叠IO就适合高性能的服务器的开发,另外完成端口是windows上比较公认的高性能服务器的网络开发模型。当然, windows 的IOCP也有个坏处,就是需要大量的内存,应为前面说了他需要事先指定缓存。不过高性能的 服务器,一般都不用windows平台。
windows的消息模型就比较适合有UI的应用程序。


郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。