Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

.NET 응용 프로그램에 기본 생성되는 스레드들에 대한 탐구

이론을 배웠으면, 검증하고 싶은 마음이 생기는데요. ^^ 이번엔, .NET 응용 프로그램에서 생성되는 '기본 스레드들'에 대해서 탐구해 볼까 합니다.

복잡한 응용 프로그램에서는 테스트하기가 어려우니까, 간단하게 "Console Application"으로 분석을 해보겠습니다.

검증 작업을 돕기 위해 몇 가지 유틸리티 함수가 필요한데요. 우선, 현재 프로그램에 실행 중인 스레드 목록을 다음과 같이 확인해 볼 수 있습니다.

static void OutputThreads()
{
    Console.WriteLine();
    int n = 0;
    foreach (ProcessThread thread in Process.GetCurrentProcess().Threads)
    {
        Console.WriteLine("[" + n + "] " + thread.Id + ", (0x" + thread.Id.ToString("x") + ")");
        n++;
    }
}

실행해 보면, 다음과 같은 식으로 결과를 보여줍니다.

[0] 6712, (0x1a38)
[1] 8976, (0x2310)
[2] 9244, (0x241c)
[3] 2280, (0x8e8)

이렇게 실행된 프로세스에 windbg로 연결하면 스레드 목록을 확인할 수 있습니다.

0:004> ~*
   0  Id: 52c.1a38 Suspend: 1 Teb: 7efdd000 Unfrozen
      Start: *** WARNING: Unable to verify checksum for D:\...\Debug\ConsoleApplication1.exe
ConsoleApplication1!COM+_Entry_Point <PERF> (ConsoleApplication1+0x2a9e) (011c2a9e) 
      Priority: 0  Priority class: 32  Affinity: ff
   1  Id: 52c.2310 Suspend: 1 Teb: 7efda000 Unfrozen
      Start: clr!DebuggerRCThread::ThreadProcStatic (7261b30c) 
      Priority: 0  Priority class: 32  Affinity: ff
   2  Id: 52c.241c Suspend: 1 Teb: 7efd7000 Unfrozen
      Start: clr!Thread::intermediateThreadProc (726fc018) 
      Priority: 2  Priority class: 32  Affinity: ff
   3  Id: 52c.08e8 Suspend: 1 Teb: 7efaf000 Unfrozen
      Start: ntdll!TppWaiterpThread (77a541f3) 
      Priority: 0  Priority class: 32  Affinity: ff
.  4  Id: 52c.128c Suspend: 1 Teb: 7efac000 Unfrozen
      Start: ntdll!DbgUiRemoteBreakin (77aaf7ea) 
      Priority: 0  Priority class: 32  Affinity: ff

원래 4개였다가 windbg를 붙이면서 5개가 되었는데, 마지막 4번 Start 함수의 ntdll!DbgUiRemoteBreakin이라는 이름에서 디버거용 스레드가 해당 프로세스에 생성된 것임을 미뤄 짐작할 수 있습니다. (따라서 4번은 무시하고!)

그 외에, 0번은 Console Application의 '주 스레드'임이 확실할 것 같고.

남은 것은 1~3번 스레드이지만, SOS 확장 DLL의 도움을 받아서 "!threads" 명령어를 실행해 보면 다음과 같이 2번 스레드가 "Finalizer"라는 것도 알 수 있습니다.

0:004> !threads
ThreadCount:      2
UnstartedThread:  0
BackgroundThread: 1
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                   PreEmptive   GC Alloc                Lock
       ID  OSID ThreadOBJ    State GC           Context       Domain   Count APT Exception
   0    1  1a38 006c7710      a020 Enabled  02822310:02823fe8 006bc7f0     1 MTA
   2    2  241c 006d25e0      b220 Enabled  00000000:00000000 006bc7f0     0 MTA (Finalizer)

자... 이제 남은 것은 1번과 3번 스레드군요.




사실, 제가 목표한 것은 1번과 3번 중의 하나는 Concurrent GC 스레드일 것이라고 생각했었습니다. 기본적으로 app.config에 아무런 GC 설정 없이 응용 프로그램을 실행하면 적용되는 것이 Concurrent-GC인데, 별도로 2세대 힙만을 전용으로 GC하는 스레드가 존재하는 유형입니다. 이에 대해서는 유경상 님이 쓰신 GC 관련 글에서 다음의 이미지가 잘 나타내 주고 있습니다.

[Concurrent-GC 모드 (출처: http://www.simpleisbest.net/post/2011/04/25/Garbage-Collection-Modes.aspx)]
thread_type_1.png

그리고, 또 한 가지는 (제 예상으로) ThreadPool을 담당하는 스레드입니다. 전용 ThreadPool을 만들어 보신 분들은 아시겠지만, ThreadPool을 구현하려면 그것만을 담당하는 스레드 하나가 있어야만 합니다. 그래야, 스레드 풀 내에 maxThreads 수만큼 늘어난 스레드 수가 할 일이 없을 때 다시 minThreads 수로 줄어드는 식의 구현을 할 수 있기 때문입니다.

위의 가정을 바탕으로 테스트를 진행해 볼 텐데요. ^^

우선, 그중에 하나가 ThreadPool을 관리하는지 테스트해 보려면 어떻게 해야 할까요?

제 생각에는, 보통의 상태에서 ThreadPool.QueueUserWorkItem 메서드를 수행하는 것과 1번과 3번 스레드를 강제로 죽인 상황에서 다시 ThreadPool.QueueUserWorkItem을 실행한 경우와 비교해 보면 될 것 같았습니다.

그런데, 직접 해보면 2가지 상황 모두 ThreadPool.QueueUserWorkItem으로 정상적으로 새롭게 스레드가 생성이 되고, 심지어 생성된 스레드들은 할 일을 마치고 정확히 20초 후에 종료되는 관리적인 면까지 동일하게 수행되었습니다. 아래는 제가 이에 대해 테스트한 간단한 콘솔 응용 프로그램입니다.

[정상적인 스레드들이 운용되고 있을 때의 스레드 풀 사용 변화]
thread_type_2.png

[2개의 스레드를 종료한 이후 스레드 풀을 사용했을 때의 변화]
thread_type_3.png

음... 아쉽게도 증명에 실패했습니다. ^^; 일단 더 테스트해 볼 수 있는 시나리오가 생각나지 않으므로 이에 대해서는 넘어가고.




그다음, 1번과 3번 중의 하나는 Concurrent GC용 스레드일 것이라는 가정을 테스트해 보겠습니다.

방법은 간단한데요. Concurrent GC 스레드가 2세대 힙을 GC하는 역할을 하기 때문에 1번과 3번 스레드를 모두 죽인 후, 2 세대 GC 카운트가 여전히 발생하는지를 테스트해 보면 됩니다. 코드로는 다음의 2가지 메서드를 상황에 따라 실행하면 되는 작업입니다.

private static void HeapAllocation()
{
    Console.WriteLine("Old Count: " + OutputGCCount());
    for (int i = 0; i < 1000; i++)
    {
        byte[] contents = new byte[1024 * 50];
    }
    Console.WriteLine("New Count: " + OutputGCCount());
}

static string OutputGCCount()
{
    int gen0 = GC.CollectionCount(0);
    int gen1 = GC.CollectionCount(1);
    int gen2 = GC.CollectionCount(2);

    return ("Gen 0: " + gen0 + ", Gen1: " + gen1 + ", Gen2: " + gen2);
}

아래는 실제로 제가 테스트해 본 과정입니다.

thread_type_4.png

만약, 그 두 개 중의 하나가 Concurrent-GC였다면 위와 같이 2세대 힙에 대한 GC가 발생하는 일은 없었어야 합니다. (물론, 스레드의 수에 변화가 없이 2세대 힙에 대한 GC가 발생했습니다.) 음... 이번에도 역시 증명에 실패했군요. ^^;

혹시, Concurrent-GC를 사용하지 않겠다고 app.config에 명시하면 어떻게 될까요? 초기 스레드 수가 줄어들까요? 확인을 위해 app.config에 다음과 같이 명시해봤습니다.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <runtime>
        <gcConcurrent enabled="false" />
    </runtime>
</configuration>

위와 같이 설정하게 되면, Non-Concurrent-GC가 동작하게 되고 이렇게 되면 응용 프로그램 내의 스레드가 new를 할 때마다 힙이 부족한 경우, 그런 상황을 유발한 그 스레드를 제외하고 다른 모든 Managed 스레드들은 멈추게 되고 new 할당을 시도하려던 스레드가 직접 GC를 수행하기 때문에 별도의 스레드가 필요가 없어서 예상대로라면 3개의 기본 스레드로 응용 프로그램이 시작되어야 합니다.

그러나 실행해 봤지만, 여전히 응용 프로그램 시작 시 4개의 스레드가 생성되는 것에는 변함이 없었습니다.




이 글을 시작할 때만 해도, 4개의 스레드에 대한 모든 정체를 밝히리라 ^^ 다짐했었는데, 결국 2개의 스레드만 정체를 밝히고 나머지는 더욱 혼란만 가중시켜버린 것 같습니다. 혹시, 이 글을 읽는 분들 중에서 나머지 2개에 대한 스레드의 정체를 알고 계신 분이 있거나, 혹은 정체를 밝힐 수 있는 기발한 아이디어가 있다면 덧글 부탁드리겠습니다.

(위에서 제가 한 테스트를 여러분들도 하실 수 있도록, 첨부 파일에 코드를 포함시켜 두었습니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/7/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2019-04-24 09시03분
using System;
using System.Diagnostics;
using System.Threading;

namespace Program
{
    public class Program
    {
        public static void Main(string[] args)
        {
            ThreadPool.GetMinThreads(out int workerThreads, out int completionPortThreads);
            Console.WriteLine($"workerThreads: {workerThreads}");

            OutputThreads();

            Console.WriteLine("Attach WinDBG and check!");
            Console.ReadLine();
        }

        static void OutputThreads()
        {
            int id = AppDomain.GetCurrentThreadId();

            Console.WriteLine();
            int n = 0;
            foreach (ProcessThread thread in Process.GetCurrentProcess().Threads)
            {
                string threadType = "(ThreadPool)";
                if (id == thread.Id)
                {
                    threadType = "(Managed)";
                }

                if (thread.BasePriority == 10)
                {
                    threadType = "(Finalizer)";
                }

                Console.WriteLine($"[{n}] {thread.Id}, (0x" + thread.Id.ToString("x") + $") {threadType}");
                n++;
            }
        }
    }
}
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13134정성태10/4/202245오류 유형: 820. There is a problem with AMD Radeon RX 5600 XT device. For more information, search for 'graphics device driver error code 31'
13133정성태10/4/202285Windows: 211. Windows - (commit이 아닌) reserved 메모리 사용량 확인 방법 [1]
13132정성태10/3/202248스크립트: 42. 파이썬 - latexify-py 패키지 소개 - 함수를 mathjax 식으로 표현
13131정성태10/3/202270.NET Framework: 2052. C# - Windows Forms의 데이터 바인딩 지원(DataBinding, DataSource)파일 다운로드1
13130정성태9/28/2022117.NET Framework: 2051. .NET Core/5+ - 에러 로깅을 위한 Middleware가 동작하지 않는 경우파일 다운로드1
13129정성태9/27/2022101.NET Framework: 2050. .NET Core를 IIS에서 호스팅하는 경우 .NET Framework CLR이 함께 로드되는 환경
13128정성태9/23/2022186C/C++: 158. Visual C++ - IDL 구문 중 "unsigned long"을 인식하지 못하는 #import파일 다운로드1
13127정성태9/22/2022333Windows: 210. WSL에 systemd 도입
13126정성태9/15/2022653.NET Framework: 2049. C# 11 - 정적 메서드에 대한 delegate 처리 시 cache 적용
13125정성태9/14/2022682.NET Framework: 2048. C# 11 - 구조체 필드의 자동 초기화(auto-default structs)
13124정성태9/13/2022619.NET Framework: 2047. Golang, Python, C#에서의 CRC32 사용
13123정성태9/8/2022643.NET Framework: 2046. C# 11 - 멤버(속성/필드)에 지정할 수 있는 required 예약어 추가
13122정성태8/26/2022742.NET Framework: 2045. C# 11 - 메서드 매개 변수에 대한 nameof 지원
13121정성태8/23/2022612C/C++: 157. Golang - 구조체의 slice 필드를 Reflection을 이용해 변경하는 방법
13120정성태8/19/2022712Windows: 209. Windows NT Service에서 UI를 다루는 방법
13119정성태8/18/2022779.NET Framework: 2044. .NET Core/5+ 프로젝트에서 참조 DLL이 보관된 공통 디렉터리를 지정하는 방법
13118정성태8/18/2022698.NET Framework: 2043. WPF Color의 기본 색 영역은 (sRGB가 아닌) scRGB [2]
13117정성태8/17/2022729.NET Framework: 2042. C# 11 - 파일 범위 내에서 유효한 타입 정의 (File-local types)파일 다운로드1
13116정성태8/4/2022828.NET Framework: 2041. C# - Socket.Close 시 Socket.Receive 메서드에서 예외가 발생하는 문제파일 다운로드1
13115정성태8/3/20221078.NET Framework: 2040. C# - ValueTask와 Task의 성능 비교 [1]파일 다운로드1
13114정성태8/2/2022949.NET Framework: 2039. C# - Task와 비교해 본 ValueTask 사용법파일 다운로드1
13113정성태7/31/2022842.NET Framework: 2038. C# 11 - Span 타입에 대한 패턴 매칭 (Pattern matching on ReadOnlySpan<char>)
13112정성태7/30/2022942.NET Framework: 2037. C# 11 - 목록 패턴(List patterns) [1]파일 다운로드1
13111정성태7/29/2022868.NET Framework: 2036. C# 11 - IntPtr/UIntPtr과 nint/nuint의 통합파일 다운로드1
13110정성태7/27/2022984.NET Framework: 2035. C# 11 - 새로운 연산자 ">>>" (Unsigned Right Shift)파일 다운로드1
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...