最早期的cpu基本上都是单核的 同一时间只能执行一条命令
多颗cpu
单颗cpu 多个核心
分时系统
- 任务是什么怎么抽象任务这个概念
- 任务的状态都有什么 怎么保存和恢复
- 什么时机会发生任务切换
寄存器的数量很少且可以枚举
内存在实模式和保护模式下 内存访问机制完全不同
执行体的上下文 就是一堆寄存器的值要切换执行体 只需要保存和恢复一堆寄存器的值即可
进程是操作系统从安全角度来说的隔离单位 不同进程之间基于最低授权的原则
fork 先clone再分支父子进程各干各的
早期的os 当中没有线程的概念 进程实际上承担了一部分来自线程的需求 我需要父进程的环境
协程 被称为用户态的线程
- 系统调用产生的成本
- 数据多次拷贝的开销
- 因为没有数据而阻塞产生调度重新获得执行权 产生的时间成本
- 线程的空间成本和时间成本
为了改进网络服务器的吞吐能力 现在主流的做法是 epoll 或者 IOCP(windows)机制
从系统调用次数的角度 都是产生了更多次数的系统调用 从内存拷贝来说也没有减少
真正有意见的事情是 减少了线程的数量
线程的时间成本
- 执行体切换本身的开销
- 执行体的调度开销
- 执行体之间的同步与互斥的成本
空间成本
- 执行体的执行状态
- TLS(线程局部存储)
- 执行体的堆栈
堆栈太小则可能不够用 太大则协程的空间成本过高 影响能够处理的网络请求的并发数
理想状况下 需要自动适应需要
golang
- 堆栈开始很小 只有4K 但可以按需自动增长
- 坚决干掉了线程局部存储特性的支持 让执行体更加精简
- 提供了同步 互斥 和其他常规执行体之间的通讯手段 包括大家非常喜欢的channel
- 提供了几乎所有重要的系统调用 尤其是IO请求的包装