オブジェクト指向の答えは、スレッドのリストをフィールドとして保持することです。
private readonly List<Thread> threads = new List<Thread>();
そして、新しく構築されたスレッドを最初のハンドラーのリストに追加します。
var thread = new Thread(myfunc);
thread.Start();
threads.Add(thread);
次に、2 番目のハンドラーで各スレッドを反復処理し、それぞれを順番に中止します。
foreach(var thread in threads)
thread.Abort();
しかし、ここで最も重要な点は、電話をかける正当な理由はほとんどないThread.Abort
ということです。
MSDN ページから:
スレッドがそれ自体で Abort を呼び出すと、結果は例外をスローするのと似ています。ThreadAbortException はすぐに発生し、結果は予測可能です。ただし、あるスレッドが別のスレッドで Abort を呼び出すと、実行中のコードが中断されます。静的コンストラクターが中止される可能性もあります。
まれに、これにより、そのアプリケーション ドメインでそのクラスのインスタンスが作成されなくなる場合があります。.NET Framework バージョン 1.0 および 1.1 では、finally ブロックの実行中にスレッドが中止される可能性があり、その場合、finally ブロックは中止されます。
中止されるスレッドがコードの保護された領域 (catch ブロック、finally ブロック、または制約付き実行領域など) にある場合、Abort を呼び出すスレッドはブロックされる可能性があります。Abort を呼び出すスレッドが、中止されたスレッドが必要とするロックを保持している場合、デッドロックが発生する可能性があります。
ManualResetEvent
各スレッドが周期的な間隔でポーリングするように設定するなど、何らかの形式のシグナリングを使用する方がはるかに優れています。BackgroundWorker
または、タスクのキャンセルをサポートするクラスを使用することもできます(それを呼び出しCancelAsync
て、ワーカー スレッドをCancellationPending
定期的にテストします)。.NET 4.0 を使用している場合は、TPLも使用できます。