RFC-0142：zx_thread_legacy_yield

摘要

我們建議新增新的系統呼叫 zx_thread_legacy_yield，讓呼叫執行緒將 CPU 交給其他等待執行緒。此外，當截止期限等於零時，我們會移除 zx_nanosleep 的特殊情況。系統呼叫名稱中的 legacy 表示有更適當的機制可用於達成所需行為。

提振精神

zx_nanosleep 的行為與其他所有系統呼叫的處理方式不同，也就是如果截止時間早於目前時間，則會立即傳回。目前，這是特殊情況，其中截止期限值為零表示產量。

此外，在執行階段，無法判斷是否有意將期限設為零，或是計算結果。這麼做可簡化 zx_nanosleep 的運作方式，減少開發人員需要注意的特殊情況。您可以手動將期限設為零，讓執行緒產生，也可以讓下次喚醒的結果為零 (這表示立即繼續)。

相關人員

誰會受到這項 RFC 是否通過的影響？(此為選用部分，但建議您填寫)。

協助人員：

FEC 指派的人員，負責引導此 RFC 通過 RFC 程序。

審查者：

諮詢：

社會化：設計最初是在設計文件中討論。

設計

這項提案包含對 Zircon 系統呼叫 API 的以下變更：

1. 新增 zx_thread_legacy_yield
2. 簡化 zx_nanosleep

其中 zx_thread_legacy_yield 的定義為：

/// Yields cpu to another waiting thread.
/// `options`: Reserved for future extension. Must be zero.
/// @blocking
zx_status_t zx_thread_legacy_yield(uint32_t options);

在使用者空間應用程式上呼叫 zx_thread_legacy_yield 時，呼叫執行緒會產生 CPU。options 參數可用於稍後提供提示。

當 options 等於零時，呼叫 zx_thread_legacy_yield 保證會傳回 ZX_OK。

當 zx_nanosleep 以超出單調時鐘時間的截止時間呼叫時，呼叫執行緒會進入休眠狀態，直到達到截止時間 (加上空閒時間) 為止。另一方面，如果截止時間的值等於或早於單調時鐘的時間，則會立即傳回。但如果截止時間為零，則會導致呼叫執行緒產生產生。在導入 zx_thread_legacy_yield 後，目標是移除零期限的特殊處理。

此外，必須移除 syscalls_zx_nanosleep_zero_duration 核心計數器，並導入 syscalls_zx_thread_legacy_yield 計數器。

實作

zx_nanosleep(0) 在 Fuchsia 樹狀結構外有 2 個呼叫位置(提供 sched_yield 的實作)，在樹狀結構內則有 7 個呼叫位置。這包括將工作拆分為四個 CL。

1. 引入新的系統呼叫 zx_thread_legacy_yield。
2. 將樹狀結構內的使用者遷移至 zx_thread_legacy_yield。
3. 遷移樹狀結構外的使用者。
4. 從 zx_nanosleep 移除產生過載。

CL (1) 會包含說明文件和語言繫結更新，而 CL (4) 也會更新說明文件。(1) 和 (2) 可以合併為單一 CL，但將實作與遷移作業分開似乎是更清晰的做法。

成效

除了 zx_nanosleep 路徑略有改善之外，這項變更對效能並無任何已知影響，因為分支已移除。

回溯相容性

zx_nanosleep(0) 的使用者不限於幹細胞存放區。

安全性考量

由於 zx_nanosleep(0) (現在) 等同於 zx_thread_legacy_yield(0)，因此現有程式碼和新程式碼的行為會完全相同。為避免發生任何安全性問題，zx_nanosleep 會維持不變，直到 zx_nanosleep(0) 的所有用途都已遷移至 zx_thread_legacy_yield(0)。

隱私權注意事項

這項提案不會影響隱私權。

測試

zx_thread_legacy_yield 的特性使得測試難以達到可靠的結果，但至少我們可以驗證傳回碼是否符合預期。

說明文件

我們會為 zx_thread_legacy_yield 新增其他說明文件，並更新 zx_nanosleep 的項目，移除「0 天期限」為特殊情況的說明。

缺點、替代方案和未知事項

最大的缺點和疑慮是 zx_thread_legacy_yield 存在鼓勵忙等模式的情況，但 sched_yield 已提供這項機制。這些疑慮可以透過適當的文件和最佳做法來減輕。由於這個系統呼叫的目標使用者是驅動程式，因此應仔細檢查其他用途。

我們考慮的另一個替代方案是將魔術值變更為其他值 (例如 INT_MIN)。這確實可解決計算的期限問題，但仍會保留特殊情況。這個替代方案也需要更新樹狀結構以外的使用者，因此需要與新增新的系統呼叫相同的努力。最大的缺點是，這樣做會讓 zx_nanosleep 的期限處理方式與其他處理期限的作業 (例如 zx_object_wait) 有所不同。

既有技術與參考資料

• zx_nanosleep 使用 0 做為特殊值，表示「產量」。問題是，程式碼會有效地執行可計算 0 的截止期限計算，在這種情況下，系統不會產生，而是會執行下一個「現在」陳述式。

• 含有 yield 的程式碼通常表示發生錯誤。很抱歉，在硬體缺乏適當訊號模式的驅動程式中，這類情況並不少見。