RFC-0142:zx_thread_legacy_yield

RFC-0142:zx_thread_legacy_yield
狀態已接受
區域
  • 核心
說明

導入可產生收益的專用系統呼叫

變更
  • 590273
作者
審查人員
提交日期 (年/月)2021-11-29
審查日期 (年/月)2021-10-13

摘要

建議您新增 Syscall zx_thread_legacy_yield,讓呼叫執行緒產生另一個等待執行緒中的 CPU。此外,在期限等於零時,我們會移除 zx_nanosleep 的特殊案例。Syscall 名稱中的 legacy 表示是否有更適合的機制可用,以達成所需行為。

提振精神

zx_nanosleep 的行為不同於所有其他系統呼叫處理期限的方式 (如果期限早於目前時間,則系統會立即回傳)。目前在這類特殊案例中,期限值為 0 表示產生。

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

相關人員

誰擔心是否接受這個 RFC?(本節為選填,但建議填寫)。

講師:

受 FEC 指派的人員透過 RFC 程序阻斷這個 RFC。

審查者:

顧問:

社交化:設計文件初步探討的設計。

設計

本提案包含以下 Zircon syscall 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 的期限大於單時鐘時鐘的時間,呼叫執行緒會進入休眠狀態,直到達到期限 (加上 slack) 到期為止。另一方面,如果期限的值等於或早於單時鐘中的時間,則該值會立即傳回。但如果期限為零,則會導致呼叫執行緒產生。導入 zx_thread_legacy_yield 後,目標是移除無期限的特殊處理方式。

此外,您也必須移除 syscalls_zx_nanosleep_zero_duration 核心計數器,同時導入 syscalls_zx_thread_legacy_yield 計數器。

實作

zx_nanosleep(0) 有 2 個呼叫網站(提供 sched_yield 實作) 和 7 個樹狀結構內呼叫網站。這包括將工作分成四個 CL

  1. 導入新的 syscall 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) 的使用者不限於 stem 存放區。

安全性考量

由於 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 的項目,移除提及零期限為特殊情況的內容。

缺點、替代方案和未知

最大的缺點和顧慮是 zx_thread_legacy_yield 積極的等待模式,但 sched_yield 已提供此機制。這些疑慮可透過適當的說明文件和最佳做法來緩解。由於這個系統呼叫的目標使用者是驅動因素,因此您應仔細檢查任何其他使用情形。

另一個替代做法是將魔術值變更為其他替代值 (例如 INT_MIN)。這確實可以解決算出的期限問題,同時保留了特殊案例。此替代方法也必須更新樹狀結構使用者,因此需要新增與新增系統呼叫一樣的操作。最大的缺點是,這樣做會讓 zx_nanosleep 期限處理是其他會處理期限的作業 (例如 zx_object_wait) 的特殊作業。

先前的圖片和參考資料

  • zx_nanosleep 使用 0 做為特殊值來表示「yield」。問題是,有程式碼能有效執行期限計算,在本範例中不會計算 0。在這種情況下,如果意圖不是產生,則相反:執行下一個陳述式「現在」。

  • 包含 yield 的程式碼通常表示發生錯誤。遺憾的是,在硬體缺少正確訊號模式的驅動程式中並不常見。