プロジェクトで数千行の複雑なマルチスレッド「C」コードを書き終えたばかりの開発者として、将来このコードに不慣れな他の開発者によって拡張、変更などが行われる予定です。皆さんは、そのようなコードにどのようなセーフティ ネットを入れようとしていますか? 例として、私はこれらを行うことができます：
あなたが書いたマルチスレッド コードには、どのようなセーフティ ネットが組み込まれていますか?
他の開発者がそのようなコードを変更したときに、どのような問題に直面しましたか?
そのようなコードには、どのような種類のデバッグ支援が組み込まれていますか?
コメントしてくれてありがとう。
私たちの製品 (アプリケーションの並行性のバグを見つけるのに役立つように設計されたハイパーバイザー) には、より一般的に役立つ多くの機能があります。コード自体でこれらを行っていることに注意してください (ソフトウェアの高度な同時実行部分であるため)。これらのいくつかは、並行コードを記述しているかどうかに関係なく役立ちます。
あなたと同じように、assert(lock_held(...)) を使用して使用することができます。
また、(独自のスケジューラがあるため) システム内でアクティブなスレッドが他にないことを期待する (まれな) 状況で assert(single_threaded()) を実行できます。
あるスレッドから別のスレッドへのメモリの破損は非常に一般的な (そしてデバッグが難しい) ため、これに対処するために 2 つのことを行います。定期的に (get_thread_id() 関数で) 「validate_thread_stack()」関数を呼び出して、これらの Cookie をチェックし、スタックが破損していないことを確認します。
私たちの malloc は、メモリの malloc ブロックの前後にマジック クッキーを貼り付け、これらを無料でチェックします。誰かがデータをオーバーランした場合、これらを使用して破損を早期に発見できます。
free() では、よく知られているパターン (この場合は 0xdddd...) をメモリ上で爆発させます。これは、そのメモリ領域にダングリング ポインターが残っている他の人をうまく破損させます。
スレッド スタックの下部近くにガード ページ (アドレス空間にマップされていないメモリ ページ) があります。スレッドがスタックをオーバーランした場合、ページ フォールトを介してキャッチし、デバッガーにドロップします。
私たちのロックが目撃されています。FreeBSD ロック監視コードをチェックアウトします。そのようなものですが、自家製です。基本的に、witness コードは、ロック取得グラフのサイクルを見て潜在的なデッドロックを検出する軽量な方法です。
私たちのロックは、取得と解放のファイル/行番号を記録するアクセサでもラップされています。二重ロック解除または二重ロックの場合、失敗に関するかなりのデバッグ情報が得られます。
当社のロックもプロファイリングされています。コードが機能するようになったら、それをうまく機能させたいと思うでしょう。取得数、取得にかかった時間などの通常のことを追跡します。
私たちのシステムでは、ロックが競合しないことを期待しています (このようにコードを慎重に設計しました)。そのため、私たちのシステムでスピン ロックを 1 秒または 2 秒以上待つと、デバッガーにドロップされます。
アトミックに更新されることを意図した変数は、C 構造体の内部にラップされています。この理由は、適切な使用法を組み合わせたずさんなコードを防ぐためです。var++ の不適切な使用。後者のコードを書くのは非常に困難です。
「揮発性」は、コンパイラによってあいまいに実装されているため、コードベースでは禁止されています。同期をうまくまとめようとするのは悪い方法です。
もちろんコードレビューも。並行性の仮定とロック規則を同僚に説明できない場合は、間違いなくコードに問題があります:-)
他の開発者がコードのサブセクションを単独で表示するときに同期スコープを見逃さないように、すべてを完全に明確にしてください。
たとえば、複数のファイルにまたがるコードでロックを保持しないでください。
あなたはあなた自身の質問に答えたようです：コードにたくさんのアサーションを入れてください。彼らは他の開発者にどの不変条件と前提条件が保持されなければならないかを教えてくれます。