Thread 개체의 Interrupt와 Abort의 차이점

Abort는 흔히 아시는 것처럼, 해당 스레드를 강제로 종료합니다. 그런데, Interrupt는 뭘까요? MSDN을 찾아보면 좀 더 명확하겠지요. ^^

즉, 스레드가 Wait/Sleep/Join 상태에 있는 경우에만 (종료시키지 않고) ThreadInterruptedException 예외를 발생시키는 기능을 합니다. 만약 스레드가 그 상태가 아닌 시점에 Interrupt 메서드를 부르면 예외를 발생하라는 표시만 되고 이후 스레드가 Wait/Sleep/Join 상태에 진입하면 그때에서야 ThreadInterruptedException 예외가 발생하게 됩니다.

더 이야기를 진행하기 전에, 그렇다면 스레드는 어떤 경우에 Wait/Sleep/Join 상태에 빠지는 걸까요?

Sleep은 간단하게 Thread.Sleep을 호출했을 때 빠지는 상태이고.
Wait은... 예를 들어 다음과 같이 EventWaitHandle.WaitOne과 같은 유의 메서드를 호출했을 때 설정됩니다.

Thread thread = new Thread(ThreadToWait);
thread.Name = "ThreadToWait";
thread.Start();

static void ThreadToWait(object state)
{
    EventWaitHandle ewh = new EventWaitHandle(false, EventResetMode.ManualReset);

    ewh.WaitOne();
}

Join은 다른 스레드를 생성한 후 그 스레드가 종료될 때까지 기다리는 Join 호출을 했을 때 빠져듭니다.

Thread targetThrad = new Thread(TestThread);
targetThrad.Start();
targetThrad.Join();

이렇게 Sleep/Wait/Join의 상황이 다르긴 하지만 Thread.ThreadState 속성에서는 이 모든 상태를 WaitSleepJoin이라는 단일한 값으로 처리해 버립니다.

---

그렇다면, Interrupt가 굳이 필요한 이유가 있을까요? 왜 특이하게 WaitSleepJoin 상태에 스레드가 진입했을 때만 해당 스레드에 ThreadInterruptedException 예외를 발생시켜주는 것일까요?

여러 다른 이유가 있을 수 있겠지만, 제 개인적인 상황에서는 이런 식의 처리가 필요할 때가 있었습니다. 예를 들어, WorkItem 단위로 처리하는 Queue를 생각해 볼 수 있는데, 대표적으로 Producer/Consumer 구조입니다.

이해를 돕기 위해 예제 코드가 있으면 편하겠지요. ^^

AutoReset, ManualReset, Monitor.Wait의 차이
; https://www.sysnet.pe.kr/2/0/1015

위의 글에 나온 코드를 잠깐 살펴보면,

EventWaitHandle waitEvent = new EventWaitHandle(false, EventResetMode.AutoReset);

void ThreadRun(object state)
{
    while (true)
    {
        waitEvent.WaitOne();
        if (threadAllExit == true)
        {
            break;
        }

        WaitCallback callback = workList.Dequeue();
        callback();
    }
}

이런 식으로 작업을 수행하는 스레드를 외부에서 '강제 종료'하고 싶을 수 있습니다. 이 때, callback() 호출 단계에서 스레드를 Abort로 강제 종료해 버리면, 코드 구성에 따라 어뗜 경우에는 프로그램 내부의 데이터 상태가 불안정하게 될 수 있습니다. 따라서 이런 경우, '현재 처리하고 있는 작업은 마저 완료하고 나서 스레드를 종료해라'라고 하고 싶을 때가 바로 'Interrupt' 메서드 호출의 적당한 사례가 되는 것입니다. (물론, 위의 글에 보면 EventWaitHandle 개체를 하나 더 해서 Interrupt와 유사한 기능을 구현하고 있지만.)

(첨부된 파일은 WaitSleepJoin 상태의 코드를 각각 Interrupt를 호출해 본 예제 프로젝트입니다.)

---

다음은, 참고 삼아서 Thread.Abort의 소스 코드를 살펴본 과정을 기록으로 남깁니다.

.NET Reflector로 보면 내부적으로 AbortInternal을 호출하게 되는데, 여기서부터는 C++ 코드가 관여하므로 더 이상 추적이 안됩니다.

[MethodImplAttribute(MethodImplOptions.InternalCall)]
private extern void AbortInternal();

굳이 파헤치려면 SSCLI 소스 코드를 따라가야 하는데요. 우선, "\clr\src\vm\ecall.cpp" 파일에 다음과 같이 매핑된 정보를 찾을 수 있고,

FCFuncElement("AbortInternal", ThreadNative::Abort)

같은 폴더의 comsynchronizable.cpp 파일에서 Abort 함수 정의를 다음과 같이 볼 수 있습니다.

FCIMPL1(void, ThreadNative::Abort, ThreadBaseObject* pThis)
{
    ...[생략]...
        thread->UserAbort(Thread::TAR_Thread, testAbort == 1 ? EEPolicy::TA_Safe : EEPolicy::TA_Rude, INFINITE, Thread::UAC_Normal);
    ...[생략]...
}
FCIMPLEND

역시 같은 폴더의 threads.cpp 파일에서 UserAbort를 찾을 수 있고,

HRESULT
Thread::UserAbort(ThreadAbortRequester requester,
                  EEPolicy::ThreadAbortTypes abortType,
                  DWORD timeout,
                  UserAbort_Client client
                 )
{
    ...[생략]...
}

UserAbort의 내용은... 길어서 생략! ^^

---

[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[최초 등록일: 12/25/2011]
[최종 수정일: 7/10/2021]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com