CppCon 2026:從「發布與可見性」重新推導 Atomic 同步語意
CppCon 2026 議程頁 · 2026-08-14
CppCon 2026 議程已於 2026-08-14 公布 Robert Leahy 的講題「What Are We Synchronizing?」,排定 2026-09-15 14:00 MDT 於 Venue 5 舉行。這場演講不從 std::memory_order 的語法背誦切入,而是要聽眾重新回答一個更根本的問題:一個事實(fact)何時、對哪個觀察者(observer)變得可見。講者將整個 atomic 同步模型重新表述成「發布(publication)與可見性(visibility)」的推導過程,而非死記 acquire/release 規則表。
背景
多數 C++ 並發教材把 memory_order_relaxed/acquire/release/seq_cst 當成規則直接套用:寫入用 release、讀取用 acquire、需要全序時用 seq_cst。Leahy 在議程摘要中把這種做法稱為「cargo-cult synchronization」——照抄常見模式,卻答不出「這個 fence 到底防止了什麼重排序」。他的講法是從資料結構的不變量(invariant)反推需要哪一種同步邊(synchronization edge),而不是先選一種記憶體序再檢查是否夠用。
核心改動
議程摘要列出四個具體案例作為推導範例:
- outstanding-work 參照計數(reference counting)——何時遞減到零才真正代表「安全可回收」
- multi-producer 單向鏈結串列的發布(publication)
- 會被併發修改的侵入式雙向鏈結串列(intrusive doubly-linked list)
- 具備多種完成模式(completion mode)的併發操作協調
對每個案例,講者會先問「誰需要看到什麼、在什麼時間點之前」,再回頭決定該用 relaxed、acquire/release,還是額外的 atomic_thread_fence。這種由需求反推工具的順序,和一般教材由工具反推需求的順序恰好相反。摘要特別點出:很多程式碼裡的 fence 其實是裝飾性的(decorative),移除後行為不變,只是寫的人不敢動它。
影響範圍
這場演講面向的是已經懂語法、但寫 lock-free 結構時仍不確定該放哪個 memory order 的系統工程師。講者 Robert Leahy 的背景是高頻金融系統與資料庫底層開發,議程頁未附講稿或範例程式碼倉庫,實際教材要等 CppCon 現場或會後影片釋出才能驗證推導細節是否站得住腳。
LSFMM+BPF 2026:BPF CI 補上了,但穩定核心的測試缺口還在
LWN.net · 2026-08-14
2026 年 Linux Storage, Filesystem, Memory-Management, and BPF Summit(LSFMM+BPF)於今年五月第一週在克羅埃西亞札格雷布(Zagreb)舉行,BPF 議程的收尾是兩場關於測試的連續 session。Ihor Solodrai 談 BPF 持續整合(CI)系統目前的狀態與演進,Shung-Hsi Yu 接著談穩定核心(stable kernel)上 BPF 更新的測試缺口。LWN 的會後報導於 2026-08-14 刊出,兩位講者的共同結論是:上游 CI 已經算堪用,但仍有幾個明確可以改進的方向。
背景
BPF 子系統的 CI 由多個元件拼起來:一個追蹤上游 BPF 開發的 kernel 樹、連接 Patchwork patch 管理系統與 GitHub 的守護行程、來自 libbpf 專案的可重用 GitHub Actions,以及自建(self-hosted)runner。工作流程定義本身放在 kernel-patches/vmtest 這個倉庫,測試在 QEMU 虛擬機裡跑,涵蓋 selftests/bpf 的主要測試套件,以及專門抓效能與驗證器回歸的 veristat。
核心討論
Solodrai 的部分聚焦在 CI 這幾年的演進與現況;Yu 的部分則指出一個結構性問題:當一個 BPF 修正被回填(backport)到穩定核心時,對應的 selftest 往往沒有一起回填。這代表穩定核心上的 BPF 行為即使有修正,也可能缺乏測試覆蓋去驗證修正確實生效,或有沒有回歸。Yu 提到他已經和穩定核心維護者 Greg Kroah-Hartman 談過,對方同意接受 BPF selftests 進入 stable 樹——但前提是要有人主動辨識出哪些 selftest 該回填,並提出申請,目前沒有自動化流程做這件事。
這個缺口的風險不只是覆蓋率數字不好看。BPF 驗證器(verifier)的改動經常被視為資安相關(security-relevant),因為驗證器的正確性直接決定使用者能否用精心構造的 BPF 程式繞過核心的安全檢查。若驗證器的穩定核心回填缺少對應測試,等於在安全敏感路徑上留下沒有回歸保護的視窗。
影響範圍
兩場 session 目前都停留在「指出方向」的階段,還沒有對應的 patch 或流程變更合入。可預期的下一步是由 BPF 維護者建立一套機制,篩選哪些 selftest 需要跟著修正一起回填到 stable,以及持續評估 CI 覆蓋率是否需要擴大到更多核心版本組合。
原始來源:LWN:BPF, continuous testing, and stable kernels、kernel-patches/vmtest
首屆 Python Packaging Council 選舉開跑:17 人搶 5 席
Python Software Foundation · 2026-08-13
Python Software Foundation(PSF)於 2026-08-13 公布首屆 Python Packaging Council 選舉候選人名單,17 人角逐 5 個席次,投票將於 2026-09-01 至 2026-09-15 進行。這個新設的治理機構源自 PEP 772,已於 2026 年 4 月 16 日由 Python Steering Council 正式接受,賦予它對打包標準、工具與實作擁有廣泛權限,地位類比於既有的 Steering Council。
背景
在 PEP 772 之前,Python 打包相關的 PEP 由 Steering Council 個別授權(standing delegation)給特定個人裁決,沒有統一的治理實體。PEP 772 通過後,Steering Council 會發出正式的整體授權給 Packaging Council,取代原本零散的個人授權關係。新機構和 Steering Council 一樣,傾向盡量少動用強制權力,而是把力氣花在建立標準流程上。
選舉時程與世代制
候選人須為 PSF 會員,選舉時程如下:
| 階段 | 日期(UTC) |
|---|---|
| 提名開放 | 2026-07-28 14:00 |
| 提名截止 | 2026-08-11 14:00 |
| 候選人公布 | 2026-08-13 |
| 投票資格確認截止 | 2026-08-25 14:00 |
| 投票開放 | 2026-09-01 14:00 |
| 投票截止 | 2026-09-15 14:00 |
首屆選舉採取交錯任期的世代制(cohort):得票最高的 2 人進入 Cohort A,任期兩年;接下來得票第 3 到第 5 名進入 Cohort B,任期一年。之後每屆選舉改為整批兩年任期,但因為兩個世代錯開改選,理論上每年只會有約一半席次同時改選。
候選人組成
17 位候選人涵蓋了打包工具鏈裡幾乎每一個關鍵專案的維護者,包括:
- Pradyun Gedam(Bloomberg)—— pip 維護者、CPython 核心開發者
- Paul Moore —— 跨互通標準的 PEP delegate、pip 維護者
- Bernat Gabor(Bloomberg)—— virtualenv、build、tox、pipx 維護者
- Donald Stufft(NVIDIA)—— PyPI 管理員、pip 核心開發者、多項 PEP 作者
- William Woodruff(OpenAI/Astral)—— PyPI 維護者,聚焦供應鏈安全
- Eli Schwartz(Gentoo)—— Meson 建置系統核心開發者
- Dan Yeaw(Anaconda)—— conda 核心維護者
- Henry Schreiner(Princeton)—— pybind11、cibuildwheel 維護者,代表科學運算社群
候選人陣容同時橫跨 pip/PyPI 陣營、conda 陣營、Meson/科學運算建置陣營,以及供應鏈安全視角,反映 Packaging Council 要處理的議題本來就橫跨這幾個過去互不隸屬的生態系。
影響範圍
選出的 5 人將決定未來打包相關 PEP 的裁決權歸屬,包括是否核准新的打包標準、介入工具間的介面爭議,以及代表 PyPA/PyPI 對外的政策立場。由於候選人來自 pip、conda、Meson 等原本各自獨立治理的工具鏈,選舉結果將直接影響這些工具未來標準化協調的難易度。