一寸一寸光阴

如下所示：p1申请R2资源2个，R2一个一共俩，给了P3进程1个，给了P2进程1个，故R2=0,则P1请求不能满足，P1阻塞，P2申请R1资源1个，R1一共仨，给了P1进程2个，P2进程1个，故R1=0，则P2请求不能满足，P2阻塞，P3进程没有请求有1个R2资源，P3正常运行，运行完之后释放R2，归还所有资源并消除与P3相连的所有边，归还后R2=1，还是不满足P1请求，P1、P2继续阻塞，所有边未被消除，则出现死锁，连着边的进程P1、P2是处于死锁状态的进程。4.进程是交互式的还是批处理式的。

第一种：A进程已经有了3个资源，还有某个资源请求使用，如果这个资源暂时得不到满足，就释放已经拿到的所有资源，以下2种破坏不剥夺让A进程自动释放已经拿到的3个资源，即使这些资源A进程还没用完，破坏了不剥夺条件，但是如果每次A进程都释放所有资源，可能出现释放了3个，再重新申请第3个资源又申请不到然后等待又主动释放拿到的2个资源，然后再重新申请3个资源，再申请第2个的时候又拿不到第2个资源，再释放已经拿到的第1个资源，依次类推，可能导致A进程出现饥饿现象。第二种：让操作系统去抢夺别的进程拿到的资源。

4.循环等待：我等你你等它又等我的环路（发生死锁一定有循环等待，但是有循环等待不代表一定发生死锁，比如下图中的白爷爷，1、2、3、4、5号和白爷爷之间有循环等待，而3号等的4号的资源和白爷爷拿的资源是一个可替代同类资源，则如果现在白爷爷释放了手中的资源，3号拿到了，那循环等待将被打破，故当是循环等待时+资源无可替代资源即唯一时，必定会发生死锁）死锁和饥饿是操作系统需要考虑的，死循环一般是程序员写的代码逻辑有问题，需要被管理者程序员考虑，三者都是一种无法向前推进的现象。1.对不可资源资源的竞争可能引起死锁。

用户1为文件1设置了口令(一般为一串字符串)，用户2访问文件1时需要提供该口令，一般口令放在文件的FCB文件控制块或者索引节点中，字符串一般占用空间不大，所以保存口令的空间开销不多，因为在访问文件时也需要把文件的FCB调入到内存，所以操作系统在验证用户提供的口令与设置的口令一致不一致花费的时间开销也较小，但是不够安全，因为存放在系统内部，可能会攻击系统?? 另外一个用户要访问该文件，只需让设置加密文件的用户告诉对应使用加密或者解密的秘钥即可，但是访问文件时解密和加密需要花费系统时间，这个秘钥啥的没存在系统中

假如用户1和用户2不再共享使用文件1，则文件1中的链接计数count=0，即文件1会被删除，此时用户3中的link文件依然存在，即真实共享文件的删除和link文件是否被删除无关，但是此时用户3再去通过link文件ccc访问文件1会报错 ，如下图所示QQ的.exe程序被删除后，再打开QQ的快捷方式会报错找不到文件。用户1创建文件1，并让文件目录项aaa指向了文件1，这个文件对应了一个索引节点，这个索引节点 包含了文件的物理地址和文件的其他属性信息+链接计数变量count(用来记录有几个用户共享了这个文件)

记录一下，但是记录了我会会吗。。。。。。。。。

操作系统