それが一種の「ルール違反」であることは知っていますが、おそらく別のスレッドからミューテックスのロックを強制的に解除するオプションを探しています。
従来のAPIではサポートされていない可能性があるため、ある種のハッキングと見なされる可能性がありますが、そのようなオプションはありますか？
私にとって興味深いシナリオの1つは、たとえば、クリーンアップが必要で、1つのスレッドが一般的なクリーンアップを実行しているが、別のスレッドがロックされたミューテックスで動作しており、待機するのは実際のオプションではない場合です。そのスレッドを解放します。
私はpthreadミューテックスを使用しています。
pthread_mutex_destroy（pthread_mutex_t * mutex）を使用して、ミューテックスを破棄できます。待機中（ロックまたはトライロック）が戻りEINVAL、「クリーンアップ」への分岐として解釈できます。注：この操作の後、mutexオブジェクトは無効になります。ただし、次のような危険性が残っています。ロックされたミューテックスを破棄しようとすると、未定義の動作が発生します。未定義の動作は、この意味で、この特別な条件に注意する必要があることを意味します。しかし、これはあなたの意図だったので、クリーンアップブランチを正しく実行し、他のスレッドがそうしていないことを確認した場合にのみ、ミューテックスによって保護されているものに触れてください。その後、破棄されたミューテックスオブジェクトを再初期化できます。
興味があるのが「クリーンアップ」だけの場合は、ロックにセマフォを使用します。待機中のスレッドをウェイクアップして終了させるために、いつでも追加のユニットを詰め込むことができます。
プロセスが終了する場合は、重要なオーバーライドの理由がない限り、とにかくクリーンアップを気にしません（「クリーンな」valgrindダンプはそれらの1つではありません:)。
ここでの問題は、特定のミューテックスの取得を待機している複数のスレッドに関連していますか。
ケースが非常に長い間保持されているスレッドの場合。以下は役立つはずであり、よりクリーンになります。コードをモジュール化して、ミューテックスを保持している関数の途中でベイルアウトできる条件を確認することをお勧めします。
複数の場所で状態をチェックすることにより、保持時間を最小限に抑え、関連するすべてのケースを処理できるはずです。