c - OpenBSD下的pthread优先级/调度

Question

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

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

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

demod_thread_fn: doing sem_wait(&data_ready)rtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data_ready was off, posting ondemod_thread_fn: past sem_waitdemod_thread_fn: calling full_demodfull_demod: about to rotate_90full_demod: after rotate_90full_demod wrote 384 bytes

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

在 OpenBSD 下我看到了这个:

demod_thread_fn: doing sem_wait(&data_ready)rtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data_ready was off, posting onrtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data in buffer is 16384 bytesrtlsdr_callback: data in buffer is 16384 bytesdemod_thread_fn: past sem_waitdemod_thread_fn: calling full_demodfull_demod: about to rotate_90full_demod: after rotate_90full_demod wrote 386 bytes

在 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 或更新版本下重试，并且更有可能工作。