Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)
(시리즈 글이 5개 있습니다.)
.NET Framework: 2008. C# - async/await 그리고 스레드 (1) MyTask로 재현
; https://www.sysnet.pe.kr/2/0/13055

.NET Framework: 2009. C# - async/await 그리고 스레드 (2) MyTask의 호출 흐름
; https://www.sysnet.pe.kr/2/0/13056

.NET Framework: 2012. C# - async/await 그리고 스레드 (3) Task.Delay 재현
; https://www.sysnet.pe.kr/2/0/13060

.NET Framework: 2014. C# - async/await 그리고 스레드 (4) 비동기 I/O 재현
; https://www.sysnet.pe.kr/2/0/13062

.NET Framework: 2075. C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)
; https://www.sysnet.pe.kr/2/0/13188




C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)

일반적으로 Task에 할당된 코드는 다음과 같은 구문으로 실행합니다.

// Windows Forms + .NET 7

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {
        System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: button1_Click");

        Task.Run(() =>
        {
            System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: Task.Run");
            this.button1.Text = "TEST";
        });
    }
}

/* 출력 결과
1: button1_Click
10: Task.Run
*/

보는 바와 같이 button1_Click 이벤트 핸들러를 실행하는 UI 스레드가 있고, Task.Run에 전달된 코드를 실행하는 스레드는 ThreadPool로부터 빌려온 것입니다. (위의 코드는 2차 스레드에서 button1을 접근하므로 예외가 발생합니다.)

여기서, Task.Run이 사용하는 스레드 운영은 TaskScheduler 타입을 상속받아 사용자 정의할 수 있습니다. 위의 경우처럼 사용자가 명시하지 않은 경우, 기본적으로는 System.Threading.Tasks.ThreadPoolTaskScheduler 타입이 사용되는데, 이 값은 TaskScheduler.Default 정적 속성으로 반환됩니다.

System.Diagnostics.Trace.WriteLine($"{TaskScheduler.Default}: TaskScheduler.Default");

// 출력 결과: System.Threading.Tasks.ThreadPoolTaskScheduler: TaskScheduler.Default

전에도 설명했지만, Task.Run은 다음의 구문과 동일하게 취급할 수 있습니다.

// 간단하게는 이렇게,
Task.Run(action);

// 복잡하게는 이렇게 호출
Task.Factory.StartNew(func, CancellationToken.None, 
                TaskCreationOptions.DenyChildAttach, TaskScheduler.Default)

TaskScheduler.Default에 설정된 ThreadPoolTaskScheduler 타입의 소스 코드는 그리 복잡하지 않은데,

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ThreadPoolTaskScheduler.cs 
; https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ThreadPoolTaskScheduler.cs

핵심 코드는 QueueTask 메서드로, 이것은 사용자 작업을 나타내는 "Task"를 ThreadPool의 스레드에 실어 실행하는 코드를 담고 있습니다.

protected internal override void QueueTask(Task task)
{
    TaskCreationOptions options = task.Options;
    if (Thread.IsThreadStartSupported && (options & TaskCreationOptions.LongRunning) != 0)
    {
        // Run LongRunning tasks on their own dedicated thread.
        new Thread(s_longRunningThreadWork)
        {
            IsBackground = true,
            Name = ".NET Long Running Task"
        }.UnsafeStart(task);
    }
    else
    {
        // Normal handling for non-LongRunning tasks.
        ThreadPool.UnsafeQueueUserWorkItemInternal(task), (options & TaskCreationOptions.PreferFairness) == 0);
    }
}

게다가 LongRunning인 경우는 별도의 Thread를 생성해 (Task 인스턴스로 대표되는) 사용자 작업을 처리합니다.

그러니까, 사실 Task 자체는 스레드에 대한 어떤 선택권도 없고, 순수하게 사용자가 맡긴 작업과 그 작업에 대한 속성을 나타내는 인스턴스에 불과한 것입니다.




자, 그럼 다른 유형의 TaskScheduler를 알아볼까요? ^^ Task와 연관돼 직접 지정하는 유형으로 FromCurrentSynchronizationContext 메서드도 별도의 TaskScheduler를 반환합니다.

private void button2_Click(object sender, EventArgs e)
{
    System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: button2_Click");

    Task.Factory.StartNew(() =>
    {
        System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: StartNew");
        this.button2.Text = "TEST";
    }, CancellationToken.None, TaskCreationOptions.None, TaskScheduler.FromCurrentSynchronizationContext());
}

/* 출력 결과:
1: button2_Click
1: StartNew
*/

보는 바와 같이 TaskScheduler를 지정하려면 Task.Factory, 즉 TaskFactory 타입을 이용해야 합니다. 그리고 이때 TaskScheduler.FromCurrentSynchronizationContext 메서드는,

// https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TaskScheduler.cs#L344

public static TaskScheduler FromCurrentSynchronizationContext()
{
    return new SynchronizationContextTaskScheduler();
}

ThreadPoolTaskScheduler보다 더 간단한 구현 코드를 갖는 SynchronizationContextTaskScheduler 인스턴스를 반환합니다.

// https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TaskScheduler.cs#L567

// 아래의 타입을 여러분의 프로젝트에 그대로 추가하는 것도 가능합니다.
// 따라서 new를 한 인스턴스를 Task.Factory.StartNew의 TaskScheduler 인자에 전달해도 됩니다.
// 당연히 동작은 닷넷의 것과 동일하므로 전체적인 수행 과정을 이해하기 위한 용도로 사용할 수 있습니다. 
internal sealed class SynchronizationContextTaskScheduler : TaskScheduler
{
    private readonly SynchronizationContext m_synchronizationContext;

    internal SynchronizationContextTaskScheduler()
    {
        m_synchronizationContext = SynchronizationContext.Current ??
            throw new InvalidOperationException("TaskScheduler_FromCurrentSynchronizationContext_NoCurrent");
    }

    protected override void QueueTask(Task task)
    {
        m_synchronizationContext.Post(s_postCallback, (object)task);
    }

    protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
    {
        if (SynchronizationContext.Current == m_synchronizationContext)
        {
            return TryExecuteTask(task);
        }
        else
        {
            return false;
        }
    }

    protected override IEnumerable<Task>? GetScheduledTasks() => null;

    public override int MaximumConcurrencyLevel => 1;

    private static readonly SendOrPostCallback s_postCallback = new SendOrPostCallback(PostCallback);

    private static void PostCallback(object? s)
    {
        // 원본 코드: ExecuteEntry가 internal이므로 호출이 불가능하기 때문에,
        //Debug.Assert(s is Task);
        //((Task)s).ExecuteEntry(); // with double-execute check because SC could be buggy

        // 수정 코드: Reflection을 이용해 호출하는 코드로 변경
        Task? task = s as Task;

        var mi = typeof(Task).GetMethod("ExecuteEntry", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
        mi?.Invoke(s, null);

        // 원본을 맞추기 위해 위의 코드를 사용했지만, 원래대로라면 이런 경우 TaskScheduler의 TryExecuteTask를 사용
        // 부모 클래스(TaskScheduler)에서 protected로 제공하는 TryExecuteTask는 task.ExecuteEntry 호출
        // 실제로 이 글의 마지막에 작성하는 SingleThreadTaskScheduler에서는 TryExecuteTask를 이용해 Task의 작업을 수행
    }
}

이 코드의 핵심도 마찬가지로 QueueTask 메서드인데, 하는 일이라고는 SynchronizationContext.Current, 위의 경우 Windows Forms이므로 System.Windows.Forms.WindowsFormsSynchronizationContextPost를 하는 것뿐입니다.

protected override void QueueTask(Task task)
{
    m_synchronizationContext.Post(s_postCallback, (object)task);
}

보는 바와 같이 (ThreadPoolTaskScheduler와는 달리) 별도의 스레드가 만들어진 것도 아니고, ThreadPool을 사용하지도 않았는데요, 따라서 위의 QueueTask와 WindowsFormsSynchronizationContext.Post 메서드까지 모두 Task.Factory.StartNew를 호출하는 스레드가 담당하게 됩니다. 물론, Post로 전달된 Delegate의 실행은 SynchronizationContext 종류에 따라 달라집니다.

이렇게 보니까 별로 신기할 것이 없죠? ^^




TaskScheduler는 사용자가 원한다면 얼마든지 새롭게 정의하는 것이 가능합니다. 예를 하나 들어볼까요? ^^ 너무 복잡하지 않은 걸로... 가령 SynchronizationContextTaskScheduler와는 달리 UI 스레드에 얽매이지는 않게 만들면서 오로지 "단일 스레드"만을 사용해 Task를 처리하는 스케줄러는 어떨까요?

일종의 STAThread 특성처럼, 호출을 (동기화가 필요 없도록) 직렬화하는 역할만 하는 것으로 대충 다음과 같이 만들 수 있습니다.

internal sealed class SingleThreadTaskScheduler : TaskScheduler
{
    static Thread _thread;
    static BlockingCollection<WorkItem> _workItems;

    class WorkItem
    {
        Task _task;
        public Task Task => _task;
        Func<Task, bool> _func;
        public Func<Task, bool> Func => _func;

        internal WorkItem(Func<Task, bool> func, Task task)
        {
            _task = task;
            _func = func;
        }
    }

    static SingleThreadTaskScheduler()
    {
        _workItems = new BlockingCollection<WorkItem>();

        _thread = new Thread(threadFunc);
        _thread.IsBackground = true;
        _thread.Start();
    }

    static void threadFunc()
    {
        while (true)
        {
            var item = _workItems.Take();
            item.Func(item.Task);
        }
    }

    protected override void QueueTask(Task task)
    {
        _workItems.Add(new WorkItem(TryExecuteTask, task));
    }

    protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
    {
        return false;
    }

    protected override IEnumerable<Task>? GetScheduledTasks() => null;
    public override int MaximumConcurrencyLevel => 1;
}

QueueTask로 들어온 작업을, 미리 static 멤버로 생성해 두었던 Thread에서 실행하도록 만들었으므로 이를 이용하면,

private void button3_Click(object sender, EventArgs e)
{
    System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: button3_Click");

    TaskScheduler staScheduler = new SingleThreadTaskScheduler();

    Task.Factory.StartNew(() =>
    {
        System.Diagnostics.Trace.WriteLine($"{Thread.CurrentThread.ManagedThreadId}: StartNew");
        this.Invoke(() => // SingleThreadTaskScheduler의 스레드에서 실행하므로 Control.Invoke 처리 필요
        {
            this.button3.Text = "TEST";
        });

    }, CancellationToken.None, TaskCreationOptions.None, staScheduler);
}

/* 출력 결과:
1: button3_Click
12: StartNew
*/

button3_Click을 몇 번을 실행해도 "StartNew" 출력은 매번 12번 스레드에서 실행되는 것을 확인할 수 있습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 5/15/2025]

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

비밀번호

댓글 작성자
 



2025-05-15 10시28분
한 번도 궁금한 적이 없었는데,

If I mark my thread pool callback as long-running, does it still count toward the thread pool thread limit?
; https://devblogs.microsoft.com/oldnewthing/20250514-00/?p=111178

닷넷에서도 마찬가지로 TaskCreationOptions.LongRunning으로 힌트를 준 경우 (본문에서 설명했듯이) 새로운 스레드를 생성해서 반환해 주는데, 그렇다면 그것은 ThreadPool의 관리 하에 놓일까요?... 라는 해답을 위의 글에서 C/C++ 기준으로 해주고 있습니다. ^^ 답은 Yes인데, 아마 닷넷도 마찬가지일 것으로 봅니다.
정성태

... 46  47  48  49  [50]  51  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12727정성태7/21/202118498.NET Framework: 1078. C# 단위 테스트 - MSTestv2/NUnit의 Assert.Inconclusive 사용법(?) [1]
12726정성태7/21/202117911VS.NET IDE: 169. 비주얼 스튜디오 - 단위 테스트 선택 시 MSTestv2 외의 xUnit, NUnit 사용법 [1]
12725정성태7/21/202116704오류 유형: 741. Failed to find the "go" binary in either GOROOT() or PATH
12724정성태7/21/202119796개발 환경 구성: 582. 윈도우 환경에서 Visual Studio Code + Go (Zip) 개발 환경 [1]
12723정성태7/21/202115599오류 유형: 740. SharePoint - Alternate access mappings have not been configured 경고
12722정성태7/20/202115766오류 유형: 739. MSVCR110.dll이 없어 exe 실행이 안 되는 경우
12721정성태7/20/202121592오류 유형: 738. The trust relationship between this workstation and the primary domain failed. - 세 번째 이야기
12720정성태7/19/202116861Linux: 43. .NET Core/5+ 응용 프로그램의 Ubuntu (Debian) 패키지 준비
12719정성태7/19/202115795오류 유형: 737. SharePoint 설치 시 "0x800710D8 The object identifier does not represent a valid object." 오류 발생
12718정성태7/19/202115259개발 환경 구성: 581. Windows에서 WSL로 파일 복사 시 root 소유권으로 적용되는 문제파일 다운로드1
12717정성태7/18/202115987Windows: 195. robocopy에서 파일의 ADS(Alternate Data Stream) 정보 복사를 제외하는 방법
12716정성태7/17/202116470개발 환경 구성: 580. msbuild의 Exec Task에 robocopy를 사용하는 방법파일 다운로드1
12715정성태7/17/202123783오류 유형: 736. Windows - MySQL zip 파일 버전의 "mysqld --skip-grant-tables" 실행 시 비정상 종료 [1]
12714정성태7/16/202116982오류 유형: 735. VCRUNTIME140.dll, MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll이 없어 exe 실행이 안 되는 경우
12713정성태7/16/202119327.NET Framework: 1077. C# - 동기 방식이면서 비동기 규약을 따르게 만드는 Task.FromResult파일 다운로드1
12712정성태7/15/202117856개발 환경 구성: 579. Azure - 리눅스 호스팅의 Site Extension 제작 방법
12711정성태7/15/202117193개발 환경 구성: 578. Azure - Java Web App Service를 위한 Site Extension 제작 방법
12710정성태7/15/202120858개발 환경 구성: 577. MQTT - emqx.io 서비스 소개
12709정성태7/14/202116353Linux: 42. 실행 중인 docker 컨테이너에 대한 구동 시점의 docker run 명령어를 확인하는 방법
12708정성태7/14/202120766Linux: 41. 리눅스 환경에서 디스크 용량 부족 시 원인 분석 방법
12707정성태7/14/202187046오류 유형: 734. MySQL - Authentication method 'caching_sha2_password' not supported by any of the available plugins.
12706정성태7/14/202118369.NET Framework: 1076. C# - AsyncLocal 기능을 CallContext만으로 구현하는 방법 [2]파일 다운로드1
12705정성태7/13/202119172VS.NET IDE: 168. x64 DLL 프로젝트의 컨트롤이 Visual Studio의 Designer에서 보이지 않는 문제 - 두 번째 이야기
12704정성태7/12/202117630개발 환경 구성: 576. Azure VM의 서비스를 Azure Web App Service에서만 접근하도록 NSG 설정을 제한하는 방법
12703정성태7/11/202122602개발 환경 구성: 575. Azure VM에 (ICMP) ping을 허용하는 방법
12702정성태7/11/202119085오류 유형: 733. TaskScheduler에 등록된 wacs.exe의 Let's Encrypt 인증서 업데이트 문제
... 46  47  48  49  [50]  51  52  53  54  55  56  57  58  59  60  ...