作者: 雪山肥鱼
时间：20210430 22:14
目的：事件并发简介

# 背景
# 简介：An Event Loop
# 重要的基础API： select()
  ## select()举例 一
  ## select()举例 二
  ## 为什么更简单? 无锁
# 问题: 阻塞的系统调用
# 问题: 状态的管理
# 问题: event-based 其他困难
# 小结

背景

在现代的操作系统中，基于事件的并发越发流行。比如node.js.
Event-base concurrency 针对两层问题。

管理并发的正确性，比如死锁，活锁，等其他多线程问题
多线程问题中，程序员几乎没有权限控制调度。程序员只是简单的创建了线程，依赖OS去合理的调度。
要实现一个在各种不同负载下，都能够良好运行的通用调度程序，是极有难度的。因此，某些时候操作系统的调度并不是最优的。
不用多线程，去构建并发服务器，同时保证对并发的控制，且避免之前多线程面临的问题，是个问题的关键

简介：An Event loop

等待事件的发生
检查事件类型
做事情：I/O request or 调度其他事件

//even loop
while(1) {
  events = getEvents();
  for( e in events)
    processEvent(e);
}

当事件正在处理时，他是系统中唯一发生的事件。所以调度器要做的就是下一个事件是什么。对调度的掌控是event based contorl 的一大优点。
那么如何准确的决定下一个事件是什么，特别是当考虑到 network 和 disk 的 I/O。
特别是一个event based server 如何判断一条消息属于它的消息是否已经到达。

重要的基础API: select( ) (or poll)

select() & poll 的目的：
检查是否有任何应该关注的输入I/O。如网络应用程序(web 服务器) 希望检查是否有网络数据包已经到达，以便为他们提供服务。

int select(int nfds, 
               fd_set * readfds,
               fd_set * writefds,
               fd_set * errorfds,
               struct timval * timeout);

nfds，检测后续参数中每一个 fds_set 中 0 到第 nfds-1 个 fdS
slecect 检测 readfds(准备好读)， writefd(准备好写)， errorfds(准备好接受意外事件)， timeout(超时)。

注意点：

select 可以让你同时检查是否有可读的文件描述符，是否有可写的文件描述符。

可读：有包进来，读包, 处理包
可写：写入数据把包发出去

2.超时设置成NULL，代表 select 可以等下去，直到某个fd准备就绪(不太理解这个准备就绪，是有数据要读可写？)，当然也可以设置超时事件。
select 和 poll 的原理大致相同。
当然还有epoll 我们后续讨论
这些基于事件的api构造了非阻塞的事件循环。可以用来检查从sockets 传来的数据，并在需要时做出回复。

select ( ) 举例。

#include 
#include 
#include 
#include 
#include 

int main(void) {
  //open and setup a bunch of sockets (not shown)
  //main loop  
  while(1) {
      fd_set readFDs;
      FD_ZERO(&readFDs);
      
      // now set the bits for the descriptors
      // this server is intrested in
      // for simplicity, all of threm from imn to max)
      
      int fd;
      for (fd = minFD; fd < maxFD; fd++)
          FD_SET(fd, &readFDs);
      // do the select
      int rc = select(maxFD +1, &readFDs, NULL, NULL, NULL);
      
       // check wich acturally have data using FD_INSSET()
      int fd;
      for(fd = minFD; fd < maxFD; fd++)
          if(FD_ISSET(fd, &readFDs))
              processFD(fd);
  }
}

假设开了很多socktes，我们用select 查看哪些网络描述符在他们上面有传入消息。

清空fd_set
设置 fd_set，我们监视从 0 到 maxFD-1 这些fd
select 检测
一旦select 返回，重新过一遍fd_set 的每一个 fd。得到数据并处理。
真正的服务器要比者复杂的多。涉及在发送消息，发出磁盘I/O和许多其他细节。后续继续学习 UNIX 环境高级编程把。

为什么更简单? 无锁

在单cpu 和基于事件的应用中，不存在并行问题。特别是因为 event-based 当处理一个时间时，不会被其他线程中断，event-based是单线程的（单CPU）。
提示，不要阻塞based event server.

问题：阻塞的系统调用

当事件发起的请求中，有阻塞的系统调用该怎么处理呢？
例如客户端发向服务器发起请求，求取读服务器磁盘，并返回文件内容。就像http请求一样。
通常event handler 会发起 open() 系统调用打开文件，紧跟着一些列的read() 去读文件。当文件读入内存，服务器会发送结果给客户端。

open 和 read 函数向内存发送请求时，数据可能还不在内存中，那么就要访问硬盘，则会花费很多时间才能给client返回数据。

对于 thread-based server 来说，这不是事儿，当线程发起I/O请求时，CPU 会切换到其他线程，可以是服务器正常运行。这种I/O 复用让多线程服务看起来自然直接。
对于event - based 的服务器来说，一个事件只要block 了，那服务器就会处于idle态，会造成资源的浪费。所以，对于event-based 服务器来说，非阻塞的调用时必须的。

解决方案: 异步I/O

现代操作系统中会引入 Asynchronous I/O。App 发出系统调用，然后立刻返回。
存在另外的接口，让App 能够确定确定I/O 是否已经完成。

int aio_read();
int aio_error();

比如说异步方式去读，然后立刻返回，定期利用 aio_error()检查异步I/O是否完成。
非常明显的缺点，总是要检查 I/O（如果时100个I/O请求呢）是否已经结束，很烦。
Unix 采用的方式是中断，interrupt. 当I/O 结束时，UNIX 会发送信号给调用者，caller 就不用一直去问，I/O 有没有结束了。
轮询 vs 中断在设备系统中也经常见到。尤其时后续的I/O 设备章节。

补充：信号

kill -l 查看所有信号

信号种类.png

#include 
#include 

void main( int arg) {
  printf("stop wakin me up...\n");
}

int main(int argc, char ** argv) {
  signal(SIGHUP, handler); 
  while(1)
    ;
  return 0;
}

关于 sighup 信号的介绍，进程进程组会话之间的关系
https://blog.csdn.net/z_ryan/article/details/80952498

通常是事件+多线程 hybird approach

事件用于处理网络包
多线程/线程池用来管理未完成的I/O

另一个问题: 状态的管理

对于多线程，所有的状态都在线程独占的 stack 中
对于事件，发出异步I/O请求后，需要打包当前的程序状态，等着I/O请求完毕，再回头利用这些状态，进行后续处理。

举例多线程：

int rc = read(fd, buffer, size);
rc = write(sd, buffer,size);

read读好后，线程立刻直到去往哪一个fd（sd）里写。
对于异步的事件处理机制来说，就比较麻烦，需要定期检查 aio_error()的值，或者等着被通知 fd已经准备就绪。那么后续event-based server 收到 IO 结束的通知，该怎么做呢，应该如何找到要发送的 sd？？

在某个地方记录完成处理该事件的所需要的信息（存接下来要用到的SD）
I/O 完成时，找到所需信息（sd），处理事件

以上述代码为例。

将sd 存于某处，并且可以通过fd 查询到，比如一个 hash table
当 I/O 结束，event handler 会通过fd 查找sd。
往sd 里写东西，完成剩余工作

event-based 的其他困难

event-based 搬运到多CPU 上，就会遇到很多困难。event-based单线程的 eventhandler 优势，荡然无存。在当代多核cpu的前提背景下，无所的事件处理机制，是永远不会存在的了。
面对系统类的事件，比如 paging，在等page - fault 的时候，event 的阻塞。这类隐式的 block 难以避免，可能会造成较大的性能问题
随着事件的退役，基于事件的服务器代码难以维护，一旦一个routine从同步进化成异步，那么之前所涉及的代码都要修改，也必须要服从新的特性。阻塞事件对于服务器的性能是才难的，因此程序员必须时钟注意每个事件API 不同参数下的不同应对。
异步磁盘I/O 和异步网络I/O 还没把发进行统一和整合，这是狠难的。比如 select 管理未完成的I/O ，这涉及 select for networking 和 select for dis I/O 的组合

小结

Event-based 相较于 multi-thread 来说，提供了更好的调度掌控
但代价是面对数据的传递以及系统级（pagiging），处理起来比较繁琐，甚至很有难度。
没有哪一种是完美的。
PDZ99 尝试阅读

线程（七）: 基于事件的并发

背景

简介：An Event loop

重要的基础API: select( ) (or poll)

select ( ) 举例。

为什么更简单? 无锁

问题：阻塞的系统调用

解决方案: 异步I/O

补充：信号

另一个问题: 状态的管理

event-based 的其他困难

小结

你可能感兴趣的:(线程（七）: 基于事件的并发)

线程（七）: 基于事件的并发

背景

简介：An Event loop

重要的基础API: select( ) (or poll)

select ( ) 举例。

为什么更简单? 无锁

问题：阻塞的系统调用

解决方案: 异步I/O

补充 ： 信号

另一个问题: 状态的管理

event-based 的其他困难

小结

你可能感兴趣的:(线程（七）: 基于事件的并发)

补充：信号