私には OpenBSD への移植という奇妙な趣味があります。pthreads の問題があることはわかっていますが、2013 年 5 月にリリースされるバージョンまでアップグレードするつもりはありません。私は1つのチュートリアルを実行し、それらを必要とする私のプログラムに追加しました。動作します。
Project du jour はrtl-sdr suite のrtl_fm.cです。20 ドルのドングルを USB ポートに差し込んで、ソフトウェア無線で 24 ～ 1700 MHz にチューニングします。比較できるように、同じコンピューターを OpenBSD、古い Debian Linux、および Windows XP で起動します。OpenBSD でほぼ動作し、Linux で動作します。同じコードをあるパーティションから別のパーティションにコピーして、別の OS で再起動できます。私が取り組んでいるバージョンには、余分な printfs を追加したので、少なくとも少しは何が起こっているかがわかります。OpenBSD は復調スレッドでもっと優先度が必要なようです。
printfs を追加すると、Linux では
demod_thread_fn: sem_wait を実行中 (&data_ready) rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: data_ready がオフで、投稿中 demod_thread_fn: 過去の sem_wait demod_thread_fn: full_demod の呼び出し full_demod: 回転しようとしています_90 full_demod: 回転後 90 full_demod は 384 バイトを書き込みました
説明すると: demod_thread_fn は demod スレッドに割り当てられたメイン関数であり、data_ready と呼ばれるセマフォで sem_wait を実行することから始まります。rtlsdr_callback は、復調するデータがある場合に低レベル デバイス ドライバーによって呼び出されます。ここでは、data_ready セマフォで sem_post を実行します。demod_thread_fn は変更を認識し、full_demod を呼び出します。残りは正常で、データをファイルに書き出すことで終了します。
OpenBSD では、次のように表示されます。
demod_thread_fn: sem_wait を実行中 (&data_ready) rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: data_ready がオフで、投稿中 rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: バッファ内のデータは 16384 バイトです rtlsdr_callback: バッファ内のデータは 16384 バイトです demod_thread_fn: 過去の sem_wait demod_thread_fn: full_demod の呼び出し full_demod: 回転しようとしています_90 full_demod: 回転後 90 full_demod は 386 バイトを書き込みましたdata_ready の sem_post は、さらに約 6 個のデータのバッチが入ってくる (すべて失われる) まで気付かれず、最終的に 1 つが復調されます。結果はわかりません。printfs を追加して修正したコードはこちらです。
私の質問は、OpenBSD の下でデモスレッドの優先順位を上げる方法および/または上げることができるかどうかです。これは、OpenBSD の pthreads 実装の欠陥の 1 つですか? pthread_attr_setschedpolicy() をいじり始めたところですが、sched_get_priority_max() のマニュアル ページの最後に、「この実装はプロセス スケジューリングをサポートしていません。」と書かれています。それは私が運が悪いということですか？プロセス全体を変更しようとしているのではなく、1 つのスレッドだけを変更しようとしています。
アラン
ここでどのように答えたらよいかわかりません。文字数制限に達しました。
私は同意する傾向があります。または、少なくともバッファは、処理されるまで追加されるように固定サイズであってはなりません。何らかの理由でLinuxでも問題なく動作します。これは毎秒最大 2 メガサンプルを処理します。各バッファは約 16k で、処理されると約 400 バイトのオーディオになります。私はそれを完全には理解していませんが、その 2 MHz のスペクトルですべての会話を記録してキャプチャし、後で必要なものを復調することは可能です。しかし、Linux では、FM 放送局からリアルタイム オーディオを取得できます。もう一度 misc@openbsd.org にサインアップして、そこで質問します。
優先度を少し変更して実験しましたが、root であっても、優先度を上げることはできますが、下げることはできません。おそらく、Windowsでもコンパイルおよび実行されます。なぜ OpenBSD で動作しないのかを理解できれば、主流のコードにいくつかの ifdef を入れることができるかもしれませんが、作者が OpenBSD に対応するために後ろ向きに屈するつもりはないと思います。それはすべて非常に新しく、非常に速く動いています。