戻り値チェックの欠落以外にも、修正可能な問題がいくつかあります:
sem_destroyは呼び出されません。- シグナル/ブロードキャスト タッチ
cond_node_tターゲット スレッドを起こした後、use-after-free が発生する可能性があります。
その他のコメント:
- 省略された破棄操作は、他の操作の変更を必要とする場合があるため、POSIX で安全であると規定されている場合、条件変数を安全に破棄できます。破棄をサポートしないか、呼び出されるタイミングに厳しい制限を課すと、物事が簡素化されます。
- 本番環境の実装では、スレッドのキャンセルを処理します。
- 待機のバックアウト (スレッドのキャンセルや
pthread_cond_timedwaitに必要な場合など) タイムアウト) が問題を引き起こす可能性があります。 - あなたの実装はユーザーランドでスレッドをキューに入れます。これは、パフォーマンス上の理由から一部の実稼働実装で行われます。正確な理由はわかりません。
- あなたの実装では、スレッドは常に LIFO 順でキューに入れられます。これは多くの場合 (キャッシュ効果などにより) 高速ですが、飢餓につながる可能性があります。製品の実装では、枯渇を避けるために FIFO 順序を使用する場合があります。
基本的にあなたの戦略は問題ないように見えますが、大きな危険が 1 つあります。未定義の動作がいくつかあります。
- POSIX 関数の戻り値を調べていません。特に
sem_wait割り込み可能であるため、負荷が高い場合や運が悪い場合、スレッドが誤って起動されます。そのすべてを注意深くキャッチする必要があります - どの関数も値を返しません。関数の一部のユーザーがいつか戻り値を使用することを決定した場合、これは未定義の動作です。条件関数が返すことを許可されているエラー コードを慎重に分析し、それを実行してください。
mallocのリターンをキャストしないでください またはcalloc
編集: 実際、malloc は必要ありません /free まったく。ローカル変数も同様です。