pthread 与 ucontext 的性能特征

Question

我正在尝试将使用 ucontext 的库移植到支持 pthreads 但不支持 ucontext 的平台。代码写得很好，所以用对 pthread 例程的调用替换所有对 ucontext API 的调用应该相对容易。但是，这是否会引入大量额外开销？或者这是一个令人满意的替代品。我不确定 ucontext 如何映射到操作系统线程，而这个工具的目的是让协程生成变得相当便宜和容易。

那么，问题是：用 pthread 调用替换 ucontext 调用会显着改变库的性能特征吗？

Answer 1

pthread 将使用系统调用，以及少量的管理内存。假设需要相同数量的系统调用，它应该与 ucontext 相当（我会天真地使用 strace 进行检查）。

出于同样的原因，swapcontext() 比使用一些 longjmp 技巧要慢（请参阅 this page，了解作者声称对他的应用程序性能影响 7 倍的讨论）。

我不是这方面的专家，但我使用协程 spice-gtk 开发了一个库，并且我们有使用 ucontext/jmp、gthread 或 winfibers 的后端。我没有注意到任何性能变化，但这可能是因为 lib 通常是 IO 绑定的。