164 lines
8.3 KiB
Markdown
164 lines
8.3 KiB
Markdown
# 12 · 并发与异步
|
||
|
||
0/21 项已确认。当前推进 12-01；本分类尚未完成选择。
|
||
|
||
本页整理原讨论的问题、验收要求和候选方案。勾选代表讨论中已确认的规则，不代表编译器或运行时已经实现。
|
||
|
||
## 12-01 可变状态的共享规则
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定普通可变值默认能否跨执行单位共享，以及允许共享的条件、违规后果。
|
||
|
||
## 12-02 数据跨边界传递
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定参数、闭包捕获和消息采用复制、共享还是转移；明确嵌套引用及发送后继续访问的规则。依赖：对象与类型模型。
|
||
|
||
## 12-03 支持哪些执行单位
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定是否提供线程、任务、协程或其他单位，明确各自能力及相互关系；不支持的单位也明确记录。
|
||
|
||
## 12-04 并行能力与边界
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定哪些执行单位允许同时执行，哪些必须串行，以及程序能否依赖特定并行度。
|
||
|
||
## 12-05 创建、启动与生命周期
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定工作何时启动、由谁管理、能否脱离创建者，以及作用域退出时如何处理未结束工作。
|
||
|
||
## 12-06 等待结果与失败传播
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定等待一次或多次的行为、结果保存方式、未观察错误，以及多个子任务失败时的处理。依赖：异常与错误处理。
|
||
|
||
## 12-07 异步暂停与调用规则
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定暂停是否显式、哪些上下文允许等待、可等待值的协议，以及普通调用与异步调用如何组合。依赖：函数与定制协议。
|
||
|
||
## 12-08 阻塞操作与异步的衔接
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定同步 I/O、阻塞调用进入任务后的行为，以及是否提供转交线程等机制；明确误用后果。
|
||
|
||
## 12-09 取消与清理
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定谁能请求取消、何时生效、能否屏蔽、如何观察取消，以及清理代码能否继续等待。依赖：资源管理、异常与错误处理。
|
||
|
||
## 12-10 超时与竞争等待
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定超时是否取消工作、多路等待如何选胜者、同时完成如何处理，以及落选工作由谁回收。
|
||
|
||
## 12-11 调度与进展保证
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定切换时机、协作式或抢占式约束、饥饿与公平性保证，以及执行单位能否迁移线程。
|
||
|
||
## 12-12 显式同步工具
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定支持哪些锁、条件变量或信号量；明确重入、持锁暂停、取消等待和死锁的处理。
|
||
|
||
## 12-13 消息与通道
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定是否支持消息机制；若支持，明确顺序、容量、背压、关闭、发送失败与接收结束的行为。
|
||
|
||
## 12-14 原子操作
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定是否提供原子值及操作；若支持，明确操作范围、内存顺序和不支持的值类型。依赖：类型系统、数值与基础类型。
|
||
|
||
## 12-15 内存可见性与数据竞争
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确同步建立什么可见性保证，以及未同步冲突访问是被拒绝、报错，还是具有某种规定的后果。
|
||
|
||
## 12-16 运行时自身的并发保护
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确 GIL、对象级锁、隔离堆等候选机制必须保障什么，以及哪些实现选择可以保留自由；区分运行时安全与用户操作的原子性。依赖：运行时实现。
|
||
|
||
## 12-17 复合操作与重入
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确单次安全操作能否组合成事务；规定回调、用户代码重入及跨多个值维护不变量时的保证。依赖：对象与定制协议。
|
||
|
||
## 12-18 资源与对象生命周期的交互
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确任务退出、共享对象存活、资源关闭、终结处理与并发访问发生冲突时的规则。依赖：内存管理、资源管理。
|
||
|
||
## 12-19 外部代码与外来线程
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定是否支持外部阻塞调用、外来线程进入语言和跨边界回调；明确同步责任及违规后果。依赖：外部接口、运行时实现。
|
||
|
||
## 12-20 执行上下文与局部状态
|
||
|
||
- [ ] 待讨论
|
||
|
||
确定线程局部、任务局部或等价机制是否存在，以及创建、迁移、取消时如何继承和释放。
|
||
|
||
## 12-21 跨分类一致性与最终验收
|
||
|
||
- [ ] 待讨论
|
||
|
||
用代表性场景检查上述规则能否共同成立，解决跨分类冲突，并形成最终规则摘要。
|
||
|
||
## 当前问题的方案与语言对照
|
||
|
||
以下沿用原讨论材料；建议和参考语言的做法均不自动成为本语言规则。
|
||
|
||
当前仍是 **12-01：普通可变数据能否跨执行单位直接共享，以及谁负责保证安全。** 这里允许不同边界采用不同规则，例如同一线程内的任务与可能并行的工作之间，可以有不同限制。
|
||
|
||
现有语言提供了四种有用的参考：
|
||
|
||
| 语言 | 规则与具体行为 | 好处、代价及启发 |
|
||
|---|---|---|
|
||
| **Python** | 同一解释器中的线程可以持有同一个列表、字典等对象。程序员可以用同一把锁保护“检查库存＋扣减”。GIL 是 CPython 的实现机制；CPython 也有自由线程构建，内置容器的内部保护不能替代业务同步。[官方文档](https://docs.python.org/3.14/howto/free-threading-python.html) | 共享方便，但同步责任主要由程序员承担。启发：必须分别说明“对象内部安全”和“整段业务操作正确”。 |
|
||
| **JS／TS** | 同一 JS agent 内的异步工作可以访问同一个普通对象；跨 `await` 的操作仍可能交错。浏览器 Worker 之间通常通过消息复制或转移数据，不能直接共享普通对象；共享内存可显式使用 `SharedArrayBuffer`，配合原子操作。Worker 属于宿主提供的机制。[ECMAScript](https://tc39.es/ecma262/multipage/executable-code-and-execution-contexts.html#sec-agents)、[HTML 标准](https://html.spec.whatwg.org/multipage/workers.html) | 普通对象跨 Worker 的隔离减少直接共享风险，但有传递成本；显式共享内存增加复杂性。启发：可以采用“局部共享、跨并行边界默认隔离”。 |
|
||
| **Go** | goroutine 可以直接共享变量，但冲突访问必须同步。例如两个 goroutine 访问同一库存，可以用 `sync.Mutex` 保护；也可以让一个 goroutine 管理库存，其他工作通过 channel 请求。channel 不会自动剥夺发送者对所发送指针的访问权。[内存模型](https://go.dev/ref/mem)、[Effective Go](https://go.dev/doc/effective_go#sharing) | 共享内存和消息协作都方便；“发送后不再访问”通常需要程序员遵守。启发：提供消息工具与强制隔离是两个不同决定。 |
|
||
| **Rust** | 安全 Rust 通过所有权、借用和跨线程约束限制危险共享。共享修改库存可以使用 `Arc<Mutex<库存>>`；访问锁内数据需要取得锁守卫，普通 `Rc` 则不能直接跨线程传递。[官方教程](https://doc.rust-lang.org/book/ch16-03-shared-state.html) | 能提前拒绝部分危险访问，但规则和类型更复杂，也仍可能死锁或出现业务竞态。启发：可以把“满足条件才能共享”做成可检查的规则。 |
|
||
|
||
其中，**TS 没有独立的并发运行时**，实际行为依赖生成的 JS 和宿主环境。`readonly` 等静态限制也不会自动提供运行时冻结或同步保护。[TS 对象类型文档](https://www.typescriptlang.org/docs/handbook/2/objects.html#readonly-properties)
|
||
|
||
回到我们的三个候选方向：
|
||
|
||
- **A．默认允许共享，使用者负责同步。** 接近 Python 线程、Go 共享变量的使用方式。表达直接，但容易遗漏同步。
|
||
- **B．跨并行边界默认隔离，通过消息协作。** 可以参考浏览器 Worker 的普通对象边界。管理责任清楚，但必须明确复制、转移和响应规则。
|
||
- **C．只有满足检查规则才能共享或转移。** 可以参考 Rust。能更早发现危险用法，但依赖更完整的别名、所有权或运行期检查设计。
|
||
|
||
**我的暂定建议是优先考虑 B**：先让普通可变数据跨并行边界的归属清楚，再讨论是否提供显式共享机制。它也有成本：频繁交换大型数据时，需要认真设计传递方式。如果我们的目标更偏向细粒度共享和底层控制，C 值得优先考虑。这个建议尚未成为决定。
|
||
|
||
你更倾向 **A 的直接共享、B 的默认隔离，还是 C 的受检查共享**？如果你的偏好是“同一线程内共享、跨并行边界隔离”，也可以直接这样确定方向。
|
||
|
||
## 讨论来源
|
||
|
||
《语言设计 12：并发与异步》，整理日期 2026-10-28。章节编号沿用原清单。
|
||
|