C OpenBSD下的pthread优先级/调度

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

《每日计划》是一个来自美国的rtl_fm.c项目。拿一个20美元的加密狗，插入USB端口，用软件定义的收音机调谐24-1700MHz。我将同一台计算机引导到OpenBSD、旧的DebianLinux和WindowsXP中，以便进行比较。它几乎可以在OpenBSD下工作，也可以在Linux下工作。我可以将相同的代码从一个分区复制到另一个分区，然后重新启动到另一个操作系统。我正在开发的版本已经添加了额外的printfs，这样我至少可以稍微了解一下发生了什么。OpenBSD在解调线程中似乎需要更高的优先级

添加了printfs后，在Linux下我看到 解调线程：正在执行扫描等待（&data）准备就绪 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：数据_就绪已关闭，正在发布 解调线程fn：已过扫描等待 解调器线程：调用完整解调器 全解调器：即将旋转90 全解调：旋转90度后 全解调器写入384字节

解释：demod_thread_fn是分配给demod线程的主要功能，它首先对名为data_ready的信号量执行sem_等待。当底层设备驱动程序有数据要解调时，它会调用rtlsdr_回调。在这里，它在数据就绪信号量上执行sem_post。demod_thread_fn看到更改，调用full_demod，其余都正常，最后将数据写入文件

在OpenBSD下，我看到以下内容： 解调线程：正在执行扫描等待（&data）准备就绪 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：数据_就绪已关闭，正在发布 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：缓冲区中的数据为16384字节 rtlsdr_回调：缓冲区中的数据为16384字节 解调线程fn：已过扫描等待 解调器线程：调用完整解调器 全解调器：即将旋转90 全解调：旋转90度后 全解调器写入386字节 sem_在data_ready上发布的帖子直到又收到6批数据（全部丢失），最后一批数据被解调后才被注意到。结果是不可理解的。添加了printfs的修改后的代码

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

艾伦

我不知道你应该怎么回答，我遇到了一个字符限制

---

我倾向于同意，或者至少缓冲区不应该是一个固定的大小，以便在处理之前添加它。但出于某些原因，它在Linux下运行良好。这玩意儿每秒可以做2兆的采样，每个缓冲区大约是16k，一旦被处理，它就会变成400字节的音频。我不完全理解它，但它可以记录和捕捉在2兆赫的频谱，然后解调你以后想要的每一个对话。但在Linux中，我可以从调频广播电台获得实时音频。我要报名参加misc@openbsd.org再问一次

---

我做了一些改变优先级的实验，但即使作为root用户，我也只能提高优先级，而不能降低优先级。据说它也在Windows下编译和运行。如果我能弄清楚为什么它不能在OpenBSD下工作，我也许能在主流代码中加入一些ifdef，但我不认为作者会为了适应OpenBSD而竭尽全力。这一切都是非常新的，而且进展非常快。

在那里使用的OpenBSD版本有一个userland线程库，它有各种折衷之处，包括阻塞文件描述符的一些意外行为。请在5.1或更高版本下重试，该版本有内核支持的线程，并且更有可能工作。

看起来/听起来更像是一个糟糕的驱动程序界面，而不是一个需要通过优先级旋转来处理的问题。如果驱动程序要填充缓冲区并发出信号量以使缓冲区处理线程就绪，则每次运行时都应将其加载到单独的缓冲区实例中，否则很可能会覆盖数据。我倾向于同意，或者至少缓冲区不应该是一个固定的大小，这样它就可以被添加到缓冲区中，直到它被处理。但出于某些原因，它在Linux下运行良好。这玩意儿每秒可以做2兆的采样，每个缓冲区大约是16k，一旦被处理，它就会变成400字节的音频。我不完全理解它，但它可以记录和捕捉在2兆赫的频谱，然后解调你以后想要的每一个对话。但在Linux中，我可以从调频广播电台获得实时音频。我要报名参加misc@openbsd.org再次询问。谢谢，我正在另一台5.2以下的机器上试用，仍然有问题，但略有不同。任何使用线程的Osmocom程序套件在最好的情况下都不工作，在最坏的情况下都无法转储内核。这让我想知道新的线程库以及它的测试有多好。它实际上运行得相当好。不过，在某些事情上，它是故意严格的。 demod_thread_fn: doing sem_wait(&data_ready) rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data_ready was off, posting on demod_thread_fn: past sem_wait demod_thread_fn: calling full_demod full_demod: about to rotate_90 full_demod: after rotate_90 full_demod wrote 384 bytes demod_thread_fn: doing sem_wait(&data_ready) rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data_ready was off, posting on rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes rtlsdr_callback: data in buffer is 16384 bytes demod_thread_fn: past sem_wait demod_thread_fn: calling full_demod full_demod: about to rotate_90 full_demod: after rotate_90 full_demod wrote 386 bytes