我有一个奇怪的爱好，就是把东西移植到OpenBSD。我知道它有pthreads问题，但在2013年5月发布之前我不会升级。我使用的是5.0，对pthreads还不太熟悉。我已经完成了1个教程，将它们添加到我的一个需要它们的程序中，它工作了。
项目du jour是来自the rtl-sdr suite的rtl_fm.c。拿一个20美元的加密狗，把它插进USB端口，用软件定义的收音机调谐24-1700兆赫。我将同一台计算机引导到OpenBSD、一个旧的Debian Linux和Windows XP中，以便进行比较。它几乎在OpenBSD下工作，在Linux下工作。我可以将相同的代码从一个分区复制到另一个分区，然后重新启动到另一个操作系统。我正在开发的版本中添加了额外的printfs，这样我至少可以看到一些情况。OpenBSD在解调线程中似乎需要更高的优先级。
添加了printfs之后，在Linux下我看到
解调线程：执行扫描等待（数据就绪）
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_callback:data_ready已关闭，正在发布
解调线程：通过扫描等待
demod_thread_fn：调用full_demod
全解调：即将旋转90度
全解调：旋转90度后
完整解调器写入384字节
说明：demod_thread_fn是分配给demod线程的主要函数，它首先对一个称为data_ready的信号量执行sem_wait。rtlsdr_回调由低级设备驱动程序在有数据要解调时调用。在这里，它对数据就绪信号量进行扫描。demod_thread_fn看到变化，调用full_demod，其余正常，最后将数据写入文件。
在OpenBSD下，我看到：
解调线程：执行扫描等待（数据就绪）
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_callback:data_ready已关闭，正在发布
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_回调：缓冲区中的数据为16384字节
rtlsdr_回调：缓冲区中的数据为16384字节
解调线程：通过扫描等待
demod_thread_fn：调用full_demod
全解调：即将旋转90度
全解调：旋转90度后
全解调器写入386字节
直到又有6批数据（全部丢失）进来，最后一批数据被解调，才注意到sem-post on-data-ready。结果不可理解。添加printfs后我修改的代码is here.
我的问题是如何和/或是否可以在OpenBSD下提高demod线程的优先级。这是OpenBSD的pthreads实现中的缺陷之一吗？我刚刚开始处理pthread_attr_setschedpolicy（），但是在sched_get_priority_max（）的手册页末尾，它说“这个实现不支持进程调度”。是不是说我运气不好？我不是想改变整个过程，只是一个线索。
艾伦
我不知道你该怎么回答，我遇到了一个字符限制。
我倾向于同意，或者至少缓冲区不应该是固定大小，以便在处理之前添加到其中。但由于某些原因，它在Linux下运行良好。这件事做高达每秒2兆样本，每个缓冲约16k，这成为约400字节的音频一旦处理。我不完全理解它，但它是有可能记录和捕捉每一个对话，在那2兆赫的频谱，然后解调你想要的稍后。但在Linux中，我可以从调频广播电台获得实时音频。我会再次注册到[email protected]并询问那里。
我做了一些改变优先级的实验，但即使是作为根用户，我也只能提高优先级，而不能降低优先级。据说它也在Windows下编译和运行。如果我能弄清楚为什么它在OpenBSD下不起作用，我也许能在主流代码中加入一些ifdef，但我不认为作者会为了适应OpenBSD而向后弯腰。一切都很新而且进展很快。
最佳答案
在那里使用的OpenBSD版本有一个userland线程库，它有各种折衷方案，包括一些阻止文件描述符的意外行为。请在5.1或更高版本下重试，该版本具有内核支持的线程，并且工作的可能性要大得多。