我有这个把事情移植到OpenBSD的奇怪爱好。我知道它有pthreads问题，但我不会升级到2013年5月发布的版本。我使用的是5.0，而且我对pthreads相当新。我已经完成了1个教程，将它们添加到我需要它们的程序中，它可以工作。
Project du jour是来自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: 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是分配给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 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 bytesdata_ready上的sem_post直到大约6个批次的数据进入（全部丢失）才被注意到，最后一个被解调。结果无法理解。我修改后的printfs代码添加了is here.
我的问题是如何和/或是否可以在OpenBSD下提高demod线程的优先级。这是OpenBSD的pthreads实现中的一个缺陷吗？我刚刚开始使用pthread_attr_setschedpolicy（），但是在sched_get_priority_max（）的手册页的末尾，它说“这个实现不支持进程调度。”。这是否意味着我运气不好？我不是要改变整个过程，只是一个线程。
艾伦
我不确定你应该怎么回答这里，我遇到了一个角色限制。
我倾向于同意，或者至少缓冲区不应该是固定大小，以便在处理之前添加它。出于某种原因，它在Linux下运行良好。这个东西每秒最多2个megasamples，每个缓冲区大约是16k，一旦处理完就变成大约400字节的音频。我不完全理解它，但是可以记录并捕获2 MHz频谱中的每个对话，然后解调你想要的内容。但在Linux中我可以从FM广播电台获得实时音频。我会再次注册misc@openbsd.org并在那里问。
我确实尝试了一点改变优先级但是作为root我只能提高优先级数，而不是降低它。据说它也可以在Windows下编译和运行。如果我能弄清楚为什么它在OpenBSD下不起作用，我可能会在主流代码中得到一些ifdef，但我不认为作者会向后弯腰以适应OpenBSD。这一切都很新，移动得非常快。
答案 0 :(得分：0)
在那里使用的OpenBSD版本有一个用户态线程库，它有各种各样的妥协，包括阻塞文件描述符的一些意外行为。在5.1或更新版本下重试，它具有内核支持的线程，并且更有可能工作。