OpenBSD 下的 pthread 优先级/调度

Question

我有一个将东西移植到 OpenBSD 的奇怪爱好。我知道它有 pthreads 问题，但在 2013 年 5 月发布的版本之前我不会升级。我使用的是 5.0，而且我对 pthreads 还很陌生。我已经完成了 1 个教程，将它们添加到我需要它们的程序中，它可以工作。

今日项目是来自the rtl-sdr suite 的rtl_fm.c。拿一个 20 美元的加密狗，将其插入 USB 端口，使用软件定义的收音机调谐 24 - 1700 MHz。我将同一台计算机引导到 OpenBSD、旧的 Debian Linux 和 Windows XP，以便进行比较。它几乎可以在 OpenBSD 下运行，也可以在 Linux 下运行。我可以将相同的代码从一个分区复制到另一个分区并重新启动到另一个操作系统。我正在开发的版本添加了额外的 printfs，因此我至少可以看到发生了什么。 OpenBSD 在解调线程中似乎需要更高的优先级。

添加了我的 printfs，在 Linux 下我看到了

demod_thread_fn: 做 sem_wait(&data_ready) rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：data_ready 已关闭，正在发布 demod_thread_fn：过去 sem_wait demod_thread_fn：调用 full_demod full_demod：即将旋转_90 full_demod：rotate_90 之后 full_demod 写了 384 字节

解释一下：demod_thread_fn 是分配给解调线程的主函数，它首先对一个名为 data_ready 的信号量执行 sem_wait。 rtlsdr_callback 在有数据要解调时由低级设备驱动程序调用。在这里，它在 data_ready 信号量上执行 sem_post。 demod_thread_fn 看到变化，调用 full_demod，其余正常，以将数据写入文件结束。

在 OpenBSD 下，我看到：

demod_thread_fn: 做 sem_wait(&data_ready) rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：data_ready 已关闭，正在发布 rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：缓冲区中的数据为 16384 字节 rtlsdr_callback：缓冲区中的数据为 16384 字节 demod_thread_fn：过去 sem_wait demod_thread_fn：调用 full_demod full_demod：即将旋转_90 full_demod：rotate_90 之后 full_demod 写了 386 个字节 data_ready 上的 sem_post 直到大约 6 批数据进入（全部丢失）然后最后一个被解调后才被注意到。结果无法理解。我添加了 printfs 的修改代码is here.

我的问题是如何和/或是否可以提高 OpenBSD 下解调线程的优先级。这是 OpenBSD 的 pthreads 实现中的缺陷之一吗？我刚刚开始搞乱 pthread_attr_setschedpolicy() 但是在 sched_get_priority_max() 的手册页末尾它说“这个实现不支持进程调度。”。这是否意味着我运气不好？我不是想改变整个过程，只是一个线程。

艾伦

我不知道你应该如何回答这里，我遇到了字符限制。

我倾向于同意，或者至少缓冲区不应该是固定大小，以便它被添加到它被处理之前。尽管出于某种原因，它在 Linux 下运行良好。这个东西每秒最多 2 兆采样，每个缓冲大约 16k，一旦处理就变成大约 400 字节的音频。我不完全理解它，但是可以记录和捕获该 2 MHz 频谱中的每个对话，然后解调您想要的内容。但在 Linux 中，我可以从 FM 广播电台获得实时音频。我会再次注册 misc@openbsd.org 并在那里询问。

我对更改优先级做了一些实验，但即使是 root，我也只能提高优先级，不能降低它。据说它也可以在 Windows 下编译和运行。如果我能弄清楚为什么它在 OpenBSD 下不起作用，我可能会在主流代码中加入一些 ifdef，但我不认为作者会向后弯腰来适应 OpenBSD。这一切都非常新，而且进展非常迅速。

Answer 1

那里使用的 OpenBSD 版本有一个用户态线程库，它有各种妥协，包括一些与阻塞文件描述符有关的意外行为。在 5.1 或更高版本下重试，它具有内核支持的线程并且更有可能工作。