你管这叫操作系统源码(十六)

最新推荐文章于 2023-03-20 18:51:07 发布

wq_0708

最新推荐文章于 2023-03-20 18:51:07 发布

阅读量245

点赞数

分类专栏：操作系统文章标签： linux 操作系统

本文链接：https://blog.csdn.net/wq_0708/article/details/126337806

版权

操作系统专栏收录该内容

20 篇文章 17 订阅

订阅专栏

文章目录

进程的阻塞与唤醒
解析并执行shell命令

进程的阻塞与唤醒

上篇最后的 sleep_on 和 wake_up 是进程的阻塞与唤醒机制的实现，今天，就详细看看这块的逻辑。

首先，表示进程的数据结构是 task_struct，其中有一个 state 字段表示进程的状态，它在 Linux 0.11 里有五种枚举值。

// shed.h
#define TASK_RUNNING 0      // 运行态
#define TASK_INTERRUPTIBLE 1    // 可中断等待状态。
#define TASK_UNINTERRUPTIBLE 2  // 不可中断等待状态
#define TASK_ZOMBIE 3       // 僵死状态
#define TASK_STOPPED 4      // 停止

当进程首次被创建时，也就是 fork 函数执行后，它的初始状态是 0，也就是运行态:

// system_call.s
_sys_fork:
    ...
    call _copy_process
    ...

// fork.c
int copy_process(...) {
    ...
    p->state = TASK_RUNNING;
    ...
}

只有当处于运行态的进程，才会被调度机制选中，送入 CPU 开始执行

// sched.c
void schedule (void) {
    ...
    if ((*p)->state == TASK_RUNNING && (*p)->counter > c) {
        ...
        next = i;
    }
    ...
    switch_to (next);
}

以上我简单列出了关键代码，基本可以描绘进程调度的大体框架了，不熟悉的朋友回顾下系列之八中如果让你来设计进程调度

所以，使得一个进程阻塞的方法非常简单，并不需要什么魔法，只需要将其 state 字段，变成非 TASK_RUNNING 也就是非运行态，即可让它暂时不被 CPU 调度，也就达到了阻塞的效果。

同样，唤醒也非常简单，就是再将对应进程的 state 字段变成 TASK_RUNNING 即可。

Linux 0.11 中的阻塞与唤醒，就是 sleep_on 和 wake_up 函数。

其中 sleep_on 函数将 state 变为 TASK_UNINTERRUPTIBLE

// sched.c
void sleep_on (struct task_struct **p) {
    struct task_struct *tmp;
    ...
    tmp = *p;
    *p = current;
    current->state = TASK_UNINTERRUPTIBLE;
    schedule();
    if (tmp)
        tmp->state = 0;
}

而 wake_up 函数将 state 变回为 TASK_RUNNING，也就是 0:

// sched.c
void wake_up (struct task_struct **p) {
    (**p).state = 0;
}

当然 sleep_on 函数除了改变 state 状态之外，还有些难理解的操作，我们先试着来分析一下。

当首次调用 sleep_on 函数时，比如 tty_read 在 secondary 队列为空时调用 sleep_on，传入的 *p 为 NULL，因为此时还没有等待 secondary 这个队列的任务:

struct tty_queue {
    ... 
    struct task_struct * proc_list;
};

struct tty_struct {
    ...
    struct tty_queue secondary;
};

int tty_read(unsigned channel, char * buf, int nr) {
    ...
    sleep_if_empty(&tty->secondary);
    ...
}

static void sleep_if_empty(struct tty_queue * queue) {
    ...
    interruptible_sleep_on(&queue->proc_list);
    ...   
}

通过 tmp = *p 和 *p = current 两个赋值操作，此时：

tmp = NULL

*p = 当前任务

同时也使得 proc_list 指向了当前任务的 task_struct：

ch19-3

当有另一个进程调用了 tty_read 读取了同一个 tty 的数据时，就需要再次 sleep_on，此时携带的 *p 就是一个指向了之前的当前任务的结构体。那么经过 tmp = *p 和 *p = current 两个赋值操作后，会变成这个样子：

ch19-3a

也就是说，通过每一个当前任务所在的代码块中的 tmp 变量，总能找到上一个正在同样等待一个资源的进程，因此也就形成了一个链表。

那么，当某进程调用了 wake_up 函数唤醒 proc_list 上指向的第一个任务时，改任务变会在 sleep_on 函数执行完 schedule() 后被唤醒并执行下面的代码，把 tmp 指针指向的上一个任务也同样唤醒:

// sched.c
void sleep_on (struct task_struct **p) {
    struct task_struct *tmp;
    ...
    tmp = *p;
    *p = current;
    current->state = TASK_UNINTERRUPTIBLE;
    schedule();
    if (tmp)
        tmp->state = 0;
}

永远记住，唤醒其实就是把 state 变成 0 而已。

而上一个进程唤醒后，和这个被唤醒的进程一样，也会走过它自己的 sleep_on 函数的后半段，把它的上一个进程，也就是上上一个进程唤醒。那么上上一个进程，又会唤醒上上上一个进程，上上上一个进程，又会…

看懂了没，通过一个 wake_up 函数，以及上述这种 tmp 变量的巧妙设计，我们就能制造出唤醒的一连串连锁反应。当然，唤醒后谁能优先抢到资源，那就得看调度的时机以及调度的机制了，对我们来说相当于听天由命了。

OK，现在我们的 shell 进程，通过 read 函数，中间经过了层层封装，以及后面经过了阻塞与唤醒这一番折腾后，终于把键盘输入的字符们，成功由 tty 中的 secondary 队列，读取并存放与 buf 指向的内存地址处，接下来，就该解析并执行这条命令了：

// xv6-public sh.c
int main(void) {
    static char buf[100];
    // 读取命令
    while(getcmd(buf, sizeof(buf)) >= 0){
        // 创建新进程
        if(fork() == 0)
            // 执行命令
            runcmd(parsecmd(buf));
        // 等待进程退出
        wait();
    }
}

也就是上述函数中的 runcmd 命令

解析并执行shell命令

上节中讲了进程在读取你的命令字符串时，可能经历的进程的阻塞与唤醒，也即 Linux 0.11 中的 sleep_on 与 wake_up 函数。接下来，shell 程序就该解析并执行这条命令了：

// xv6-public sh.c
int main(void) {
    static char buf[100];
    // 读取命令
    while(getcmd(buf, sizeof(buf)) >= 0){
        // 创建新进程
        if(fork() == 0)
            // 执行命令
            runcmd(parsecmd(buf));
        // 等待进程退出
        wait();
    }
}

也就是上述函数中的 runcmd 命令。

首先 parsecmd 函数会将读取到 buf 的字符串命令做解析，生成一个 cmd 结构的变量，传入 runcmd 函数中：

// xv6-public sh.c
void runcmd(struct cmd *cmd) {
    ...
    switch(cmd->type) {
        ...
        case EXEC:
        ecmd = (struct execcmd*)cmd;
        ...
        exec(ecmd->argv[0], ecmd->argv);
        ... 
        break;
    
        case REDIR: ...
        case LIST: ...
        case PIPE: ...
        case BACK: ...
    }
}

然后就如上述代码所示，根据 cmd 的 type 字段，来判断应该如何执行这个命令。比如：

最简单的，就是直接执行，也即 EXEC。
如果命令中有分号 ; 说明是多条命令的组合，那么就当作 LIST 拆分成多条命令依次执行。
如果命令中有竖线 | 说明是管道命令，那么就当作 PIPE 拆分成两个并发的命令，同时通过管道串联起输入端和输出端，来执行。

之前的命令，很显然就是个管道命令。管道理解起来非常简单，但是实现细节却是略微复杂。所谓管道，也就是上述命令中的 |，实现的就是将 | 左边的程序的输出（stdout）作为 | 右边的程序的输入（stdin），就这么简单。

那我们看看，它是如何实现的，我们走到 runcmd 方法中的 PIPE 这个分支里，也就是当解析出输入的命令是一个管道命令时，所应该做的处理：

// xv6-public sh.c
void runcmd(struct cmd *cmd) {
    ...
    int p[2];
    ...
    case PIPE:
        pcmd = (struct pipecmd*)cmd;
        pipe(p);
        if(fork() == 0) {
            close(1);
            dup(p[1]);
            close(p[0]);
            close(p[1]);
            runcmd(pcmd->left);
        }
        if(fork() == 0) {
            close(0);
            dup(p[0]);
            close(p[0]);
            close(p[1]);
            runcmd(pcmd->right);
        }
        close(p[0]);
        close(p[1]);
        wait(0);
        wait(0);
        break;
    ...
}

首先，我们构造了一个大小为 2 的数组 p，然后作为 pipe 的参数传了进去。这个 pipe 函数，最终会调用到系统调用的 sys_pipe，我们先不看代码，通过 man page 查看 pipe 的用法与说明：

pipe

可以看到，pipe 就是创建一个管道，将传入数组 p 的 p[0] 指向这个管道的读口，p[1] 指向这个管道的写口，画图就是这样子的：

pipe_a

当然，这个管道的本质是一个文件，但是是属于管道类型的文件，所以它的本质的本质实际上是一块内存。

这块内存被当作管道文件对上层提供了像访问文件一样的读写接口，只不过其中一个进程只能读，另一个进程只能写，所以再次抽象一下就像一个管道一样，数据从一端流向了另一段。你说它是内存也行，说它是文件也行，说它是管道也行，看你抽象到哪一层了，这个之后再展开细讲，先让你迷糊迷糊。

回过头看程序：

// xv6-public sh.c
void runcmd(struct cmd *cmd) {
    ...
    int p[2];
    ...
    case PIPE:
        pcmd = (struct pipecmd*)cmd;
        pipe(p);
        if(fork() == 0) {
            close(1);
            dup(p[1]);
            close(p[0]);
            close(p[1]);
            runcmd(pcmd->left);
        }
        if(fork() == 0) {
            close(0);
            dup(p[0]);
            close(p[0]);
            close(p[1]);
            runcmd(pcmd->right);
        }
        close(p[0]);
        close(p[1]);
        wait(0);
        wait(0);
        break;
    ...
}

在调用完 pipe 搞出了这样一个管道并绑定了 p[0] 和 p[1] 之后，又分别通过 fork 创建了两个进程，其中第一个进程执行了管道左边的程序，第二个进程执行了管道右边的程序。

由于 fork 出的子进程会原封不动复制父进程打开的文件描述符，所以目前的状况如下图所示:

pipe_b

当然，由于每个进程，一开始都打开了 0 号标准输入文件描述符，1 号标准输出文件描述符和 2 号标准错误输出文件描述符，所以目前把文件描述符都展开就是这个样子。（父进程的我就省略了）

pipe_c

现在这个线条很乱，不过没关系，看代码。左边进程随后进行了如下操作：

// fs/pipe.c
...
if(fork() == 0) {
    close(1);
    dup(p[1]);
    close(p[0]);
    close(p[1]);
    runcmd(pcmd->left);
}
...

即 关闭(close) 了 1 号标准输出文件描述符，复制（dup） 了 p[1] 并填充在了 1 号文件描述符上（因为刚刚关闭后空缺出来了），然后又把 p[0] 和 p[1] 都 关闭（close） 了。

你再读读这段话，最终的效果就是，将 1 号文件描述符，也就是标准输出，指向了 p[1] 管道的写口，也就是 p[1] 原来所指向的地方：

pipe_d

同理，右边进程也进行了类似的操作：

// fs/pipe.c
...
if(fork() == 0) {
    close(0);
    dup(p[0]);
    close(p[0]);
    close(p[1]);
    runcmd(pcmd->right);
}
...

只不过，最终是将 0 号标准输入指向了管道的读口：

pipe_e

这是两个子进程的操作，再看父进程:

// xv6-public sh.c
void runcmd(struct cmd *cmd) {
    ...
    pipe(p);
    if(fork() == 0) {...}
    if(fork() == 0) {...}
    // 父进程
    close(p[0]);
    close(p[1]);
    ...
}

你没有看错，父进程仅仅是将 p[0] 和 p[1] 都关闭掉了，也就是说，父进程执行的 pipe，仅仅是为两个子进程申请的文件描述符，对于自己来说并没有用处。

那么我们忽略父进程，最终，其实就是创建了两个进程，左边进程的标准输出指向了管道（写），右边的进程的标准输入指向了同一个管道（读），看起来就是下面的样子：

pipe_f

而管道的本质就是一个文件，只不过是管道类型的文件，再本质就是一块内存。所以这一顿操作，其实就是把两个进程的文件描述符，指向了一个文件罢了，就这么点事情。那么此时，再让我们看看 sys_pipe 函数的细节：

// fs/pipe.c
int sys_pipe(unsigned long * fildes) {
    struct m_inode * inode;
    struct file * f[2];
    int fd[2];

    for(int i=0,j=0; j<2 && i<NR_FILE; i++)
        if (!file_table[i].f_count)
            (f[j++]=i+file_table)->f_count++;
    ...
    for(int i=0,j=0; j<2 && i<NR_OPEN; i++)
        if (!current->filp[i]) {
            current->filp[ fd[j]=i ] = f[j];
            j++;
        }
    ...
    if (!(inode=get_pipe_inode())) {
        current->filp[fd[0]] = current->filp[fd[1]] = NULL;
        f[0]->f_count = f[1]->f_count = 0;
        return -1;
    }
    f[0]->f_inode = f[1]->f_inode = inode;
    f[0]->f_pos = f[1]->f_pos = 0;
    f[0]->f_mode = 1;       /* read */
    f[1]->f_mode = 2;       /* write */
    put_fs_long(fd[0],0+fildes);
    put_fs_long(fd[1],1+fildes);
    return 0;
}

不出我们所料，和进程打开一个文件的步骤是差不多的，可以回顾下系列之十二中打开终端设备文件这一节，下图是进程打开一个文件时的步骤：

ch17-5

两者相同点：

都是从进程中的文件描述符表 filp 数组和系统的文件系统表 file_table 数组中寻找空闲项并绑定。

两者不同点：

打开一个文件的前提是文件已经存在了，根据文件名找到这个文件，并提取出它的 inode 信息，填充好 file 数据。
pipe 方法中并不是打开一个已存在的文件，而是创建一个新的管道类型的文件，具体是通过 get_pipe_inode 方法，返回一个 inode 结构。然后，填充了两个 file 结构的数据，都指向了这个 inode，其中一个的 f_mode 为 1 也就是写，另一个是 2 也就是读。（f_mode 为文件的操作模式属性，也就是 RW 位的值）

创建管道的方法 get_pipe_inode 方法如下：

// fs.h
#define PIPE_HEAD(inode) ((inode).i_zone[0])
#define PIPE_TAIL(inode) ((inode).i_zone[1])

// inode.c
struct m_inode * get_pipe_inode(void) {
    struct m_inode *inode = get_empty_inode()；
    inode->i_size=get_free_page()；
    inode->i_count = 2; /* sum of readers/writers */
    PIPE_HEAD(*inode) = PIPE_TAIL(*inode) = 0;
    inode->i_pipe = 1;
    return inode;
}

可以看出，正常文件的 inode 中的 i_size 表示文件大小，而管道类型文件的 i_size 表示供管道使用的这一页内存的起始地址。

OK，管道的原理在这里就说完了，最终我们就是实现了一个进程的输出指向了另一个进程的输入。

pipe_f

回到最开始的 runcmd 方法：

// xv6-public sh.c
void runcmd(struct cmd *cmd) {
    ...
    switch(cmd->type) {
        ...
        case EXEC:
        ecmd = (struct execcmd*)cmd;
        ...
        exec(ecmd->argv[0], ecmd->argv);
        ... 
        break;
    
        case REDIR: ...
        case LIST: ...
        case PIPE: ...
        case BACK: ...
    }
}

如果展开每个 switch 分支你会发现，不论是更换当前目录的 REDIR 也就是 cd 命令，还是用分号分隔开的 LIST 命令，还是我们上面讲到的 PIPE 命令，最终都会被拆解成一个个可以被解析为 EXEC 类型的命令。

EXEC 类型会执行到 exec 这个方法，在 Linux 0.11 中，最终会通过系统调用执行到 sys_execve 方法。这个方法就是最终加载并执行具体程序的过程，在系列之十三中 execve 加载并执行 shell 程序和缺页中断，我们已经讲过如何通过 execve 加载并执行 shell 程序了，并且在加载 shell 程序时，并不会立即将磁盘中的数据加载到内存，而是会在真正执行 shell 程序时，引发缺页中断，从而按需将磁盘中的数据加载到内存。

这个流程在本回我们就不再赘述了，不过当初在讲这块流程以及其它需要将数据从硬盘加载到内存的逻辑时，总是跳过这一步的细节。那么我们下篇，就彻底把这个硬盘到内存的流程拆开了讲解！