第八章：多级反馈队列 优先级的规则： 当任务刚进入操作系统的时候其优先级最高 优先级的切换： 当任务运行的时间超过时间片，则优先级降低 当任务在时间片中暂停使用CPU，则优先级不变 一个任务在未达到时间片时放弃CPU则优先级不变 对于交互式任务来说，我们不希望降低它的优先级，而希望它在某一优先级反复执行 每个任务在某一优先级的总时间不超过一个时间片，达到后则强制降低优先级，并在Boo

第七章：进程调度/介绍 参数介绍： Response：响应时间，即任务第一次运行的时间 Turnaround: 完成时刻（周转时间），即任务完成那一刻对应的时间 Wait: 等待中时间，即任务处于Ready状态，但当前CPU在执行其他任务的等待时间 执行结果如下 FIFO: 123456789101112131415161718192021ARG policy FIFOARG jlist

第六章：受限制直接执行/上下文切换 实验环境 由于该实验要求在单个CPU上运行两个进程并在他们两个UNIX管道，而书中介绍的sche_affinity()函数的具体调用不是很清楚，所以这里通过Docker的参数限制，创建了一个只使用宿主机一个CPU资源的容器进行实验。 单核Docker容器的创建 1docker run -it -d --cpuset-cpus="0" --

第五章：进程API 子进程和父进程的变量x的值内容相互独立。 1234567891011121314151617181920212223242526272829303132333435363738#include <stdio.h>#include <stdlib.h>#include <unistd.h>#include <string.h>

在写完OSTEP第五章课后习题之后，通过第八题的答案记录一下自己目前对waitpid()的尝试结果，目前的尝试仅限于进程执行的阻塞和等待，轮询和非阻塞的状态暂时没有遇到，日后补充。 进程等待 waitpid()不能用于子进程等待更早的另外一个子进程，如果尝试运行则会返回-1。（在父进程中则等待并返回子进程对应的pid) 这里举例说明，以下为一个不包含任何waitpid()的原始代码 123456

该问题为OSTEP第五章进程API上的一个问题，在搜Stack overflow的时候发现一个很好记的答案，单独写一个博客记录一下 参考回答 what-are-the-different-versions-of-exec-used-for-in-c-and-c 翻译摘抄 对于exec()函数，在C/C++中有以下几个不同的版本 1234567891011121314#include <

声明 该方法目前稳定性尚不确定，Token有概率会不定时失效，如果使用后果自负 该方法仅作Python学习使用，了解原理后使用后果自负 疫情期间请以实际情况打卡汇报，切勿身体有状况而依旧以无状况打卡。 参考文章 简单三步，用 Python 发邮件 - 知乎 (zhihu.com) github action获取仓库secrets 实现的效果 ​通过Github Actions，在每天

参考链接 Where to store my Git personal access token? GitCreadentitalManager GitCredential 简单方案 最简单的方案是讲自己的配置文件用明文保存，在文档中查询可知道指令如下 1git config --global credential.helper store 在设置credential.helper为全局s

第四章：进程 作业来自: ostep-homework 两个程序都只使用CPU，所以CPU的利用率是100%，测试可得： 123456789101112131415Time PID: 0 PID: 1 CPU IOs 1 RUN:cpu READY 1

这个月因为游戏的问题，我又犯了拖延症的老毛病，导致计划中的学习任务没有一个完成。玩起游戏的时候总会高估自己的效率，导致就想着一直玩到通关为止。规划的二月份的学习计划没有一个完成的事实，让我感到挺沮丧的。但我还是觉得要写一篇总结来记录这个月的所做所为。 做了的事情 学习方面 尝试了用Postman工具进行抓包，不过由于自己偷懒没仔细看文档以及对代理设置的不当配置，前前后后断断续续折腾了四五天还是