阻塞和非阻塞的實現
本文轉載自微信公眾號「編程雜技」，作者theanarkh。轉載本文請聯系編程雜技公眾號。
我們可能都已經聽過阻塞非阻塞的概念，本文以tcp中的connect系統調用為例子(基于1.12.13內核，新版的原理類似，但是過程就很復雜了，有時間再分析)，分析阻塞和非阻塞是什么并且看他是如何實現的。話不多說，直接開始。
- static int inet_connect(struct socket *sock, struct sockaddr * uaddr,
- int addr_len, int flags)
- {
- struct sock *sk=(struct sock *)sock->data;
- // 調用底層的連接函數，發一個syn包
- err = sk->prot->connect(sk, (struct sockaddr_in *)uaddr, addr_len);
- if (err < 0)
- return(err);
- // 還沒建立連接成功并且是非阻塞的方式，直接返回
- if (sk->state != TCP_ESTABLISHED &&(flags & O_NONBLOCK))
- return(-EINPROGRESS);
- // 早期通過關中斷防止競態情況
- cli();
- // 連接建立中，阻塞當前進程
- while(sk->state == TCP_SYN_SENT || sk->state == TCP_SYN_RECV)
- {
- // 阻塞進程
- interruptible_sleep_on(sk->sleep);
- // 連接失敗
- if(sk->err && sk->protocol == IPPROTO_TCP)
- {
- sti();
- sock->state = SS_UNCONNECTED;
- err = -sk->err;
- sk->err=0;
- return err; /* set by tcp_err() */
- }
- }
- sti();
- // 連接建立
- sock->state = SS_CONNECTED;
- // 返回成功
- return(0);
- }
我們看到connect函數首先會調用tcp層的函數發送一個sync包，然后根據socket的屬性(阻塞非阻塞，可以通過setsocketopt設置)做下一步處理，如果是非阻塞，那么就比較簡單，直接返回給應用層。這也是非阻塞+事件驅動架構中的做法。因為這種架構下通常是單進程的，要避免阻塞進程，那么返回后什么時候才能知道連接成功呢?這就是epoll提供的機制，當連接成功后，tcp層會通知epoll，epoll就會通知應用層。下面我們繼續分析阻塞的過程，interruptible_sleep_on(sk->sleep)。我們看到socket中有一個sleep字段，該字段用于管理隊列。我們看看interruptible_sleep_on
- void interruptible_sleep_on(struct wait_queue **p)
- {
- __sleep_on(p,TASK_INTERRUPTIBLE);
- }
- static inline void __sleep_on(struct wait_queue **p, int state)
- {
- unsigned long flags;
- struct wait_queue wait = { current, NULL };
- current->state = state;
- add_wait_queue(p, &wait);
- save_flags(flags);
- sti();
- schedule();
- remove_wait_queue(p, &wait);
- restore_flags(flags);
- }
這里我們只關注兩個地方add_wait_queue和schedule。add_wait_queue就是把一個節點插入隊列。我們看看wait_queue的定義。
- struct wait_queue {
- struct task_struct * task;
- struct wait_queue * next;
- };
所以add_wait_queue執行完之后架構如下。
接著調用schedule調度其他進程執行，我們發現這時候當前進程的狀態是TASK_INTERRUPTIBLE，所以是不會被調度執行的。這就是進程阻塞的原理，主要是兩個過程
1 加入等待隊列
2 讓出CPU，調度其他進程執行。
我們這個進程什么時候被喚醒呢?我們從收到sync的回包開始分析。具體邏輯在tcp_rcv中。
- if(sk->state==TCP_SYN_SENT)
- {
- /* Crossed SYN or previous junk segment */
- // 發送了syn包，收到ack包說明可能是建立連接的ack包
- if(th->ack)
- {
- // 發送第三次握手的ack包，進入連接建立狀態
- tcp_send_ack(sk->sent_seq,sk->acked_seq,sk,th,sk->daddr);
- tcp_set_state(sk, TCP_ESTABLISHED);
- // 喚醒阻塞在connect函數的進程
- if(!sk->dead)
- {
- // 喚醒進程
- sk->state_change(sk);
- // 給進程發送SIGIO信號
- sock_wake_async(sk->socket, 0);
- }
- }
- }
我們看到收到ack后，tcp層調用state_change回調，state_change的值是def_callback1。
- static void def_callback1(struct sock *sk)
- {
- if(!sk->dead)
- wake_up_interruptible(sk->sleep);
- }
我們看到這里會調用wake_up_interruptible喚醒進程。我們看看實現。
- void wake_up_interruptible(struct wait_queue **q)
- {
- struct wait_queue *tmp;
- struct task_struct * p;
- if (!q || !(tmp = *q))
- return;
- do {
- if ((p = tmp->task) != NULL) {
- if (p->state == TASK_INTERRUPTIBLE) {
- p->state = TASK_RUNNING;
- if (p->counter > current->counter + 3)
- need_resched = 1;
- }
- }
- tmp = tmp->next;
- } while (tmp != *q);
- }
我們看到wake_up_interruptible會喚醒所有進程，這就是導致景群效應的地方，新版內核已經處理了相關問題。另外我們看到，這里這是修改進程為可執行狀態，但是不會立刻調度，要等下一次進程調度的時候才發生進程調度。以上就是進程阻塞和非阻塞的原理。
