この質問は、Thread.suspend の代替案に関するものではありません。これは、Thread.suspend を使用してバイアス ロックを実装する可能性に関するものです。これは、Thread.interrupt または同様の代替手段では実装できない (と私は信じています)。
Thread.suspend が非推奨であることは知っています。
しかし、Thread.suspend の正確なセマンティクスを知りたいです。
thread1.suspend() を呼び出すと、thread1 が完全に停止するまでブロックされることが保証されますか? thread1.resume() を呼び出した場合、この呼び出しは他のスレッドに順不同で表示されますか?
さらに、スレッドの中断に成功した場合、このスレッドはある程度安全な時点で中断されますか? その中間状態を確認できますか (Java は適切に同期されていないプログラムでも薄い空気の値を禁止しているため、これが許可されているとは思いません)、それとも異常な状態を確認しますか (サスペンドが非同期要求である場合は、確実に確認できます)そういうこと）？
Java 内におもちゃの非対称ロック (HotSpot の BiasedLock など) を実装したいので、これらを知りたいです。Thread.suspend を使用すると、ストアの負荷バリアなしで Dekker のようなロックを実装できます (そして負担をまれなパスに移すことができます)。私の実験では動作することが示されていますが、Thread.sleep はリモート コンテキスト スイッチを待機するのに十分であるため、これが保証された動作であるかどうかはわかりません。
ところで、リモート バリアを強制 (または検出) する他の方法はありますか? たとえば、Web を検索すると、FlushProcessWriteBuffers を使用したり、アフィニティを変更してスレッドを各コアにバインドしたりする人がいます。これらのトリックは Java 内で実行できますか?
編集
私はアイデアを思いつきました。少なくとも 2 つのスレッドしかない場合は、GC とファイナライザーを使用してバイアス付きロックを実装できるかもしれません。残念ながら、遅いパスでは明示的な gc() 呼び出しが必要になる場合がありますが、これは実際には実用的ではありません。
GC が正確でないと、デッドロックが発生する可能性があります。GC があまりにもスマートで、参照を無効にする前にオブジェクトを収集する場合 (おそらく、コンパイラはスタック変数を再利用できますが、コンパイラは取得フェンスとロード フェンスを無視して、ヒープ変数に対してこの種のことを実行できますか?)、破損したデータになってしまいます。
編集
オプティマイザーがオブジェクトの最後の参照を上に移動するのを防ぐために、いわゆる「到達可能性フェンス」が必要なようです。残念ながらどこにもありません。