我有將這些東西移植到OpenBSD的奇怪愛好。我知道它有pthreads的問題，但我不會升級，直到2013年5月發佈的版本。我使用5.0，我是相當新的pthreads。我已經完成了1個教程，將它們添加到我需要它的程序中，它可以工作。OpenBSD下的pthread優先級/調度
Project du jour is rtl_fm.c from the rtl-sdr suite。把一個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是分配給解調線程的主要功能，它開始做一種叫做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 bytes上DATA_READY的sem_post沒有注意到，直到大約6個數據的批次都來了（全部丟失），那麼最後一個被解調。結果是不可理解的。我的修改代碼添加了printfs is here.
我的問題是如何和/或如果我可以提高OpenBSD下demod線程的優先級。這是OpenBSD的pthreads實現中的缺陷之一嗎？我剛剛開始討論pthread_attr_setschedpolicy（），但是在sched_get_priority_max（）的手冊頁末尾，它表示「此實現不支持進程調度」。這是否意味着我運氣不好？我並沒有試圖改變整個過程，只是一個線程。
艾倫
我不知道你應該怎麼回答在這裏，我遇到了一個字符的限制。
我傾向於同意，或者至少緩衝區不應該是一個固定的大小，以便它被添加到它被處理。儘管出於某種原因，它在Linux下工作正常。這個東西每秒可以達到2兆樣本，每個緩存大約爲16k，一旦處理完成，它就會變成大約400字節的音頻。我不完全理解它，但可以記錄並捕獲2 MHz頻譜中的每個對話，然後解調您以後想要的內容。但在Linux中，我可以從FM廣播電臺獲得實時音頻。我會再次註冊[email protected]並在那裏詢問。
我做了一些改變優先級的實驗，但即使作爲根我只能提高優先級數字，而不是降低它。據說它也可以在Windows下編譯和運行。如果我能弄清楚爲什麼它在OpenBSD下無法正常工作，我可能會在主流代碼中獲得一些ifdefs，但我認爲作者不會向後彎曲以適應OpenBSD。這一切都非常新穎，移動速度非常快。
看起來/聽起來像一個糟糕的驅動程序接口，而不是通過優先級處理的問題。如果驅動程序要填充一個緩衝區併發出一個信號量來使緩衝區處理線程就緒，那麼它應該在每次運行時加載到一個單獨的緩衝區實例中，否則極有可能會覆蓋數據。需要設計修復，而不是優先順序。 –
我傾向於同意，或者至少緩衝區不應該是一個固定的大小，以便它被添加，直到它被處理。儘管出於某種原因，它在Linux下工作正常。這個東西每秒可以達到2兆樣本，每個緩存大約爲16k，一旦處理完成，它就會變成大約400字節的音頻。我不完全理解它，但可以記錄並捕獲2 MHz頻譜中的每個對話，然後解調您以後想要的內容。但在Linux中，我可以從FM廣播電臺獲得實時音頻。我會再次註冊[email protected]並在那裏詢問。 – ab1jx