进程间通信（IPC）+进程加锁解锁

【0】README

0.1） source code and text description are from orange’s implemention of a os；
0.2） for complete code , please visit https://github.com/pacosonTang/Orange-s-OS/tree/master/ipc_8

【1】看看，我们的进程代码

这里写图片描述

【2】看看IPC替换系统调用 get_ticks 后的调用过程

（本图片是对 source insight 工具打开的系统调用所涉及函数的截图，图片过大，建议使用在“在新标签页中打开图片”）
这里写图片描述

对上面两张图的分析（Analysis）：（上图中的缓冲区 or 消息发送队列，进程间通信可能用到，也可能用不到）

A1）要知道进程A -> get_ticks -> send_recv -> msg_send or msg_receive 等；
A2）系统进程 task_sys 率先启动，调用send_recv(RECEIVE, ANY, &msg)即msg_receive 等待接收消息，由于没有任何进程发送消息给它，该进程阻塞；我们看看阻塞代码：
A3） 进程A启动，发送消息给 task_sys，进入系统调用msg_send，关键代码如下：
if ((p_dest->p_flags & RECEIVING) && /* dest is waiting for the msg */
```
     (p_dest->p_recvfrom == proc2pid(sender) ||p_dest->p_recvfrom == ANY)) {assert(p_dest->p_msg);assert(m);phys_copy(va2la(dest, p_dest->p_msg),va2la(proc2pid(sender), m),sizeof(MESSAGE));p_dest->p_msg = 0;p_dest->p_flags &= ~RECEIVING; /* dest has received the msg */p_dest->p_recvfrom = NO_TASK;
```
unblock(p_dest)
显然，msg_send 里面的if 语句，系统进程的结构体成员是满足的，所以进程A向系统进程 task_sys 发送消息成功，（也就是吧进程A的消息结构体内容 copy 到系统进程task_sys 的消息结构体存储空间，由函数 phys_copy 完成）
A4）消息发送成功后，返回0， send_recv 函数立即调用 ret = sendrec(RECEIVE, src_dest, msg) 即msg_receive 系统调用接收系统进程task_sys 发来的消息；因为 send_recv 中的 src_dest 是指定好了的， src_dest = task_sys（只不过，它传入的参数是task_sys 进程的进程表索引）
A5）系统进程 task_sys 收到消息后，向先前的消息发送者（进程A）发送消息，该消息封装了 ticks 的value值；
A6）系统进程 task_sys 调用 msg_send 系统调用，关键代码如下：
if ((p_dest->p_flags & RECEIVING) && /* dest is waiting for the msg */
```
     (p_dest->p_recvfrom == proc2pid(sender) ||p_dest->p_recvfrom == ANY)) {assert(p_dest->p_msg);assert(m);phys_copy(va2la(dest, p_dest->p_msg),va2la(proc2pid(sender), m),sizeof(MESSAGE));p_dest->p_msg = 0;p_dest->p_flags &= ~RECEIVING; /* dest has received the msg */p_dest->p_recvfrom = NO_TASK;
```
unblock(p_dest)
显然，msg_send 里面的if 语句，进程A 的结构体成员是满足的，所以系统进程task_sys 向进程 A 发送消息成功；

A7）进程A 收到消息，抽取出 RETVAL，关键代码如下：

    send_recv(BOTH, TASK_SYS, &msg);TASK_SYS=1return msg.RETVAL;

这里写图片描述

【3】我们看看 assert （panic类似）怎么调用的？

这里写图片描述

对sys_printx函数的分析（Analysis）：

A1）当sys_printx 发现传入字符串的第一个字符是MAG_CH_ASSERT时，会同时判断调用系统调用的进程是系统进程还是用户进程（通过 sys_printx函数中if 语句的 p_proc_ready < &proc_table[NR_TASKS]) 判断）；
A2）如果是系统进程，则停止整个系统的运转，并将要打印的字符串打印在显存的各处；
A3）如果是用户进程，则打印后像一个普通进程一样返回，届时该用户进程会因为 assertion_failure（）中对函数spin 的调用而进死循环；
Attention）：换句话说，系统进程的 assert 失败会导致系统停止运转（hlt），而用户进程的失败仅仅导致自己停转（spin）；

【4】我们接着看进程的加锁 + 解锁

以下有5副图片，第一幅图片是重中之重，给出了加锁和解锁函数的定义，以及进程切换函数 schedule，建议在分析的时候，把后4副图片和第1 副图片做对照，效果更好。

这里写图片描述
4.1）进程加锁在何时发生？（block）（这里p->p_flags 置！0 是关键）

case1）在msg_send 函数中： 如果消息接收者没有指定该消息发送者，或者接收者没有准备好接收消息，则消息发送者会添加到接收者的消息发送队列中；【在本例中，消息发送者是进程A，它是用户进程，所以进程A被阻塞（spin 死循环函数）】；
阻塞（加锁）过程解析：由于 sender->p_flags |= SENDING（参见上图代码），显然 sender->p_flags 不等于零，不会进入assert 函数，直接进入 schedule（）进行进程切换，显然 schedule 将CPU控制权切换到那些 p_flags == 0 的进程手里面；也即是只要p->p_flags !=0 ,那么该进程p 就永远也无法进行进程切换，获得CPU控制权（此谓阻塞）；
我们这里再添加p_flags 的作用，p_flags 用于表明进程的状态，取值3种（下文不再叙述有关 p_flags 的作用）：
- 1）value = 0：表明进程正在运行或准备运行；
- 2）value = SENDING（宏定义，具体你不管，反正 !0）： 表明进程处于发送消息状态，由于消息没有被送达（该进程还处于接收者进程的发送队列中），消息发送者进程被阻塞；
- 3）value = RECEIVING（宏定义，具体你不管，反正 !0）： 表明进程处于接收消息状态，由于没有接收到消息，消息接收者进程被阻塞；
case2）在msg_receive 函数中： 如果没有任何进程向当前进程发送消息的话，当前进程会阻塞，直到有进程发送消息给当前进程；【举个荔枝：在本例中，当前进程是个系统进程 task_sys，所以这样的话，整个系统会停止运转；】
阻塞（加锁）过程解析：由于 p_who_wanna_recv->p_flags |= RECEIVING （参见上图代码），显然 p_who_wanna_recv->p_flags 不等于零，不会进入assert 函数，直接进入 schedule（）进行进程切换，显然 schedule 将CPU控制权切换到那些 p_flags == 0 的进程手里面；也即是只要p->p_flags !=0 ,那么该进程p 就永远也无法进行进程切换，获得CPU控制权（此谓阻塞）；

4.2）进程解锁在何时发生？（unblock）（这里p->p_flags 置0 是关键）

case1）在msg_send 函数中：如果处于 RECEIVING 状态的进程接收到了消息，则就会对该进程进行解锁；判断p->p_flags==0，【举个荔枝：在本例中，消息接收者进程是个系统进程 task_sys，所以这样的话，整个系统会停止运转】；
解锁过程解析：由于 p_dest->p_flags &= ~RECEIVING; /* dest has received the msg */（参见上图代码），显然 p_dest->p_flags ==0，（0==0 -> TRUE）也不会进入assert 函数；紫薇曾经问过：你还记得大明湖畔的夏雨荷吗？我也来问一句：你还记得加锁过程中调用的 schedule 吗？ schedule 函数阻塞该进程的法宝就是当其 p_flags非零时，就不会对该进程进行CPU控制权的转让，因为if 语句根本就不满足；现在好了，在解锁前 p_dest->p_flags &= ~RECEIVING（因为接收到消息前，p_flags==RECEIVING，当然和~RECEIVE 进行逻辑与后得到0）；也即是原先阻塞的进程的p_flags==0 了，它就可以获得CPU控制权了（转向到schedule），这也就解锁了，Bingo！（此谓解锁）；
case2）在msg_receive 函数中：如果接收者进程接收任一消息，就从其发送队列中取出一个发送进程，然后发送进程解锁；
解锁过程解析：由于 p_from->p_flags &= ~SENDING（参见上图代码），显然 p_dest->p_flags ==0，（0==0 -> TRUE）也不会进入assert 函数；
紫薇曾经问过：你还记得大明湖畔的夏雨荷吗？我也来问一句：你还记得加锁过程中调用的 schedule 吗？ schedule 函数阻塞该进程的法宝就是当其 p_flags非零时，就不会对该进程进行CPU控制权的转让，因为if 语句根本就不满足；现在好了，在解锁前 p_dest->p_flags &= ~SENDING（因为接收到消息前，p_flags==SENDING，当然和~SENDING进行逻辑与后得到0）；也即是原先阻塞的进程的p_flags==0 了，它就可以获得CPU控制权（转向到schedule），这也就解锁了，Bingo！（此谓解锁）；