C # 스레드 종료 및 Thread.Abort ()


85

MSDN에서 Thread.Abort () 메서드에 대한 설명은 "이 메서드를 호출하면 일반적으로 스레드가 종료됩니다."라고되어 있습니다.

왜 항상 그렇지 않습니까?

어떤 경우에 스레드를 종료하지 않습니까?

스레드를 종료 할 다른 가능성이 있습니까?

답변:


60

Thread.Abort()ThreadAbortException스레드에를 주입합니다 . 스레드는를 호출하여 요청을 취소 할 수 있습니다 Thread.ResetAbort(). 또한 finally예외가 처리되기 전에 실행 되는 블록 과 같은 특정 코드 부분 이 있습니다. 어떤 이유로 스레드가 이러한 블록에 갇혀 있으면 스레드에서 예외가 발생하지 않습니다.

호출자는를 호출 할 때 스레드의 상태를 거의 제어 Abort()할 수 없으므로 일반적으로 그렇게하는 것은 바람직하지 않습니다. 대신 종료를 요청하는 메시지를 스레드에 전달하십시오.


어떤 종류의 메시지? 메서드 호출을 의미합니까?
user101375 2010

4
스레드간에 데이터를 전달하는 방법에 따라 다릅니다. 예를 들어 스레드가 작업 대기열이있는 작업자 스레드 인 경우 PleaseTerminate 메시지를 대기열에 넣고 스레드가 정상적으로 처리하도록 할 수 있습니다.
Brian Rasmussen

내 스레드에는 해결해야 할 하나의 큰 문제가 있는데 작업 대기열이 없다는 것입니다.
user101375 2010

내가 말했듯이 스레드 코드가 어떻게 설계되었는지에 따라 다릅니다. 아마도 멤버 변수를 통해 신호를 보낼 수 있습니다. 사용 가능한 실제 코드 없이는 더 구체적으로 말하기가 어렵습니다.
Brian Rasmussen

54

어떤 경우에 스레드를 종료하지 않습니까?

이 질문은 중복됩니다.

Thread.Abort () 사용시 문제점

스레드를 종료 할 수있는 다른 가능성이 있습니까?

예. 문제는 정중하게 중지하라고 말할 수없는 스레드를 시작해서는 안되며 적시에 중지된다는 것입니다. (1) 중지하기 어렵거나, (2) 버그가 있거나, 최악의 경우 (3) 사용자에게 적대적 일 수있는 스레드를 시작해야하는 상황에 있다면 올바른 방법은 다음과 같습니다. 새 프로세스를 만들고 새 프로세스에서 스레드를 시작한 다음 스레드가 중단 되기를 원할 때 프로세스종료합니다 . 비협조적인 스레드의 안전한 종료를 보장 할 수있는 유일한 방법은 운영 체제가 전체 프로세스를 중단하는 것입니다.

자세한 내용은이 질문에 대한 지나치게 긴 답변을 참조하십시오.

C #의 루프 내에서 잠금 문 사용

관련 비트는 스레드를 중단하기 전에 스레드가 스스로를 죽일 때까지 기다려야하는 시간과 관련하여 고려 사항이 무엇인지 논의하는 끝에있는 비트입니다.


Eric, 스레드가 동기화 객체를 기다리고있는 경우 어떻게 스레드가 중지하도록 정중하게 지시해야합니까 (예 : EventWaitHandle.WaitOne ();)?
Corvin

5
@Corvin : 한 스레드가 다른 스레드와 통신하는 방법을 설명하는 두 스레드 간의 계약은 해당 스레드에서 실행되는 코드 작성자에게 달려 있습니다. (1) 스레드 X가 객체를 잠재적으로 영원히 기다려야하고 (2) 해당 스레드 Y가 유한 한 시간 내에 스레드 X를 완전히 종료 할 수 있어야한다는 요구 사항이 있다면 모순되는 요구 사항이 있다고 생각합니다. 어느 것이 이길 지 결정하십시오. 전자 인 경우 스레드 Y는 기다려야합니다. 후자의 경우 스레드 X가 영원히 기다리지 않아야하며 약간의 시간을 기다려야합니다.
Eric Lippert

대답 해줘서 고마워. 다음 아키텍처를 고려하십시오. 특정 시스템 전체 이벤트가 발생할 때 자체적으로 최소화해야하는 애플리케이션이 있습니다. 해당 응용 프로그램에 글로벌 명명 된 이벤트를 대기하고 해당 이벤트가 설정되면 작업을 수행하는 스레드가 있습니다. 반면에 내 응용 프로그램은 이벤트가 발생하기 전에 종료해야 할 수 있으며 대기중인 스레드를 닫아야합니다. 그런 것을 코딩하는 사무라이 방법은 무엇입니까?
Corvin

@Corvin : 이벤트를 기다리는 (짧은 시간 제한 포함) 루프가있을 수 있으며, 대기 시도를 중지해야하는지 확인합니다 (정상 종료 할 수 있음). 이런 식으로 스레드가 중지되어야한다는 신호를 보낼 수 있으며, 중지 될 때까지 시간이 초과되는 동안 만 기다려야합니다.
Kevin Kibler

2
@Corvin, 대기중인 스레드를 백그라운드 스레드로 만들면 응용 프로그램이 종료되기 전에 닫을 필요가 없습니다.
Don Kirkby

17

왜 항상 그렇지 않습니까? 어떤 경우에 스레드를 종료하지 않습니까?

우선, 스레드는 ThreadAbortException자신의 종료를 포착 하고 취소 할 수 있습니다 . 또는 중단을 시도하는 동안 영원히 걸리는 계산을 수행 할 수 있습니다. 이 때문에 런타임은 사용자가 요청한 후에 스레드가 항상 종료된다는 것을 보장 할 수 없습니다.

ThreadAbortException 더 있습니다 :

스레드를 제거하기 위해 Abort 메서드를 호출하면 공용 언어 런타임에서 ThreadAbortException이 발생합니다. ThreadAbortException은 catch 할 수있는 특수 예외이지만 catch 블록의 끝에서 자동으로 다시 발생합니다. 이 예외가 발생하면 런타임은 스레드를 종료하기 전에 모든 finally 블록을 실행합니다. 스레드는 finally 블록에서 제한되지 않은 계산을 수행하거나 Thread.ResetAbort()중단을 취소하는 호출 을 수행 할 수 있으므로 스레드가 끝날 것이라는 보장은 없습니다.

Abort()수동으로 스레드 할 필요가 없습니다 . 스레드의 메서드가 반환되도록하면 CLR이 모든 더러운 작업을 수행합니다. 스레드가 정상적으로 종료됩니다.


해당 스레드 (Dispatcher.Run ();)에서 시작된 메시지 루프 때문에 Abort ()해야합니다. 올바르게 이해하면 스레드에 반환을 호출하는 메서드를 호출하여 완료해야합니까?
user101375 2010

7

FileStream.Read()현재 아무것도 수신하지 않는 명명 된 파이프 (수신 데이터를 기다리는 동안 호출 블록 읽기)는에 응답하지 않습니다 Thread.Abort(). Read()통화 내에 남아 있습니다 .


6

스레드가 잠금을 유지하고 중단 / 종료되면 어떻게됩니까? 리소스가 고정 된 상태로 유지

스레드가 다른 스레드가 아닌 자체 중단을 호출 할 때 제대로 작동합니다. 중단, 작업을 완료하지 않은 경우에도 영향을받는 스레드를 강제 종료하고 리소스를 정리할 기회를 제공하지 않습니다.

MSDN 참조


참조 : 관리 형 스레딩 모범 사례


5

루프에 갇힌 스레드를 중단 할 수없는 것 같습니다.

//immortal
Thread th1 = new Thread(() => { while (true) {}});

그러나 루프 중에 잠 자면 스레드를 중단 할 수 있습니다.

//mortal
Thread th2 = new Thread(() => { while (true) { Thread.Sleep(1000); }});

1
이것은 사실이 아닌 것 같습니다. 테스트 프로그램을 실행했습니다 .` {var th = new Thread (() => {int i = 0; try {while (true) {i ++;}} catch (Exception e) { Console.WriteLine ( "aborting @ {0}", i);}}); th. 시작 (); Thread.Sleep (1000); th.Abort (); th.Join (); }
Weipeng L


3

핸들러 내부에서 ThreadAbortException및 호출을 잡을 수 있기 때문 Thread.ResetAbort입니다.


0

OT : 포괄적이고 언어에 구애받지 않고 의심스럽고 유용하며 동시성에 대한 재밌는 내용은 Verity Stob !


-1

스레드가 너무 바빠서 Abort () 호출을 듣지 못하는 경우가있어 일반적으로 ThreadAbortingException이 내 코드에 throw됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.