进程间通信（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！（此谓解锁）；

进程间通信（IPC）+进程加锁解锁相关推荐

漫谈QNX（架构/进程，线程，同步，进程间通信IPC）
(1)架构说起Blackberry的QNX操作系统, 想必大家都听说过,但到底为什么QNX能如此有名?难道微软的Windows和Linux都不能与之抗衡? 美国NASA的太空接驳飞船也使用QNX操作 ...
Linux进程+进程间通信IPC
一 Linux进程 1) 进程的内存映像 2)解释 BSS段:在采用段式内存管理的架构中,BSS段(bss segment)通常是指用来存放程序中未初始化的全局变量的一块内存区域.BSS是英文Bloc ...
linux进程间通信 ipc,进程间通信IPC (InterProcess Communication)
一.进程间通信的概念每个进程各自有不同的用户地址空间,任何一个进程的全局变量在另一个进程中都看不到,所以进程之间要交换数据必须通过内核,在内核中开辟一块缓冲区,进程1把数据从用户空间拷到内核缓冲区, ...
进程间通信 IPC、LPC、RPC
原文请见:进程间通信IPC.LPC.RPC 进程间通信(IPC,Inter-Process Communication),指至少两个进程或线程间传送数据或信号的一些技术或方法.进程是计算机系统分配资源 ...
详解操作系统之进程间通信 IPC (InterProcess Communication)
进程间通信(IPC,Inter-Process Communication),指至少两个进程或线程间传送数据或信号的一些技术或方法. 进程是计算机系统分配资源的最小单位(严格说来是线程).每个进程都有 ...
Android中进程间通信(IPC)方式总结
IPC为进程间通信或跨进程通信,是指两个进程进行进程间通信的过程.在PC和移动设备上一个进程指的是一个程序或者一个应用,所以我们可以将进程间通信简单理解为不同应用之间的通信,当然这种说法并不严谨. 在 ...
linux：进程间通信 IPC
文章目录 1.管道 1.1.匿名管道 1.2.有名管道 2.信号 3.共享内存 3.1.共享内存接口 3.1.1.生成 key 值 3.1.2.创建共享内存 3.1.3.创建共享内存映射 3.1.4. ...
Linux系统编程学习笔记（九）进程间通信IPC
进程间通信IPC: 我们以前介绍过进程控制原语,看到怎么创建多个进程.但是进程之间交互信息的方式只介绍了通过fork或者exec继承父进程的打开文件或者通过文件系统. 经典的进程通信方式有:管道.FI ...
进程间通信IPC、LPC、RPC
IPC是进程间通信,有两种,它们是LPC和RPC,前者是本地过程调用后者是远程过程调用简介进程间通信(IPC,Inter-Process Communication),指至少两个进程或线程间传送 ...

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

【0】README

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

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

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

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

进程间通信（IPC）+进程加锁解锁相关推荐

最新文章

热门文章

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

【0】README

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

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

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

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

进程间通信（IPC）+进程加锁解锁相关推荐

最新文章

热门文章

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