结论： 信息不足

看起来像看不懂要写内存管理还是任务管理的一群普通大一学生在吐槽题目看不懂

如果写的是内存管理，那可能还是有顶尖学霸能随手复刻一下各种 **malloc 库实现的

如果真的是写“任务管理” 那题目不首先定义一下 task/process 内核结构体那么是没法开始动键盘的，更别说动笔了。我觉得并不能傻逼到这种程度

真不知道 lz 是故意的，还是装无知。

盲猜角蛋白酶（软化）、磨料（把皮磨下来）、糖皮质激素（防敏感抗炎症）


去角质=把表皮抹掉，泥=你的皮

10 年前
刚有微博的时候，我曾经信过互粉群
（摊手）

您要找的是不是：




.net framework

@squancher 所以说了，没有。你看起来的“实时” 就 就 就是先把状态改了等下一个时间片而已

下一个时间片分不到定时器就是不准的。就这样。

@squancher 状态改变是主动的，实时发生的，但检测状态改变，不是。

或者说 上面用户态的绝大多数情况都不需要实时感知直接触发回调

@squancher 内核中有专门结构，进程内会通过 api 来通知内核修改内核对象的值。

@squancher 假设我们实现一个慢悠悠的，没有优先级的，分片很长的调度方法


那，阻塞这件事就会变成（ A 等待 B 进程，系统有 ABCD4 个进程）
1. A 进程进入等待状态，调度器把 A 关联到 B，A 变为不可调度
2. 调度 B 进程，B 进程获得时间片，跑 1 秒，任务没结束。
3. 调度 C 进程，C 进程获得时间片，跑 1 秒
4. 调度 D 进程，D 进程获得时间片，跑 1 秒
5. 调度 A 进程，A 进程不能调度，继续选下一个
6. 调度 B 进程，B 进程获得时间片，跑 1 秒任务结束
7. 调度器发现 B 进程结束了，遍历正在等 B 的进程，发现 A，A 设为可调度
8. 调度 C 进程
9. 调度 D 进程
10. 调度 A 进程，A 进程获得时间片，取得 B 状态，跑 1 秒
11. 调度 B 进程，B 进程所有关联的等待者已不再等待，可以卸载 B 进程
12. 调度 C 进程

……

@squancher

> 就是这个问题，上面问过了，怎样判断条件，能做到实时，快速反应





不是“实时”的。
协程你理解吧，协程状态变化不是“实时的”对吧，而是被等待 routine 状态改变的时候调度器把等待进程重新设为可调度而已


进程一样的，操作系统判断被等事件状态可改变时把状态修改（为完成），同时把在等待这个事件的所有进程重新设为可调度，下次调度时就能恢复它们的执行流程



顺带一提，正因为 linux 调度器算法机制不能做到“实时”，所以 linux 并不是一个实时操作系统。RTOS 需要有硬件机制来直接通知内核立即切换进程状态并调度目的进程

努力是天赋的一部分


“别人都可以你为什么不行” 是蠢蛋逻辑，有认知能力的人应该会明白 “虽然我做不到 A，但我能做好 B”

c 太刀：刀片看着简单，但是招式花里胡哨，打得慢
java 重弩：爆发强，上满 buff 战撸一把梭
python 轻驽：用着很友好，力量有限，可以打辅助
c# 弓：用着很爽，输出也足，但一般都不会想作为主修武器
golang 斩斧：比 c 输出高，套路少，叠红刀无脑插爆（无脑 go routine ）
c 艹 盾斧：变化多机制复杂入门困难，但是能防反能超解能红斧锯个痛，打得慢。

不是踩一顶一。
但从大家的回复和反应来看

“中文编程” 是不是笑话，谁是笑话 一目了然