Microsoft MVP성태의 닷넷 이야기
.NET Framework: 611. C++ 개발자들을 위한 C# Thread 동작 방식 [링크 복사], [링크+제목 복사],
조회: 27183
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

C++ 개발자들을 위한 C# Thread 동작 방식

아래와 같은 질문이 있군요. ^^

C# 스레드 질문입니다. 
; http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&no=4517&z=

질문의 요지는 이렇습니다. C++의 경우 class에서 Thread를 사용하려면 다음과 같이 static (또는 전역 함수)로 정의된 경우여야 합니다.

#include "stdafx.h"
#include <Windows.h>

class MyClass
{
public:
    static DWORD threadFunc(void *ptr)
    {
        printf("threadFunc called!\n");
        return 0;
    }

    DWORD dummy(void *ptr) { return 0; }
};

int main()
{
    HANDLE hHandle = ::CreateThread(nullptr, 0, (LPTHREAD_START_ROUTINE) &MyClass::threadFunc, nullptr, 0, nullptr);
    ::WaitForSingleObject(hHandle, -1);

    return 0;
}

C++은 class의 static 함수의 타입을 정의된 그대로 "DWORD (*)(void *)"로 처리하는 반면, 그렇지 않은 경우에는 함수(예제에서는 dummy)의 타입에 클래스 명이 붙어 "DWORD (MyClass::*)(void *)"로 처리합니다. 게다가 이런 경우에는 강제 형 변환조차도 할 수 없도록 C++ 컴파일러 자체가 막아 버립니다.

// 아래의 코드는 컴파일러 오류 발생 (Error C2440 - 'type cast': cannot convert from 'DWORD (__thiscall MyClass::* )(void *)' to 'LPTHREAD_START_ROUTINE')

LPTHREAD_START_ROUTINE pThreadFunc = (LPTHREAD_START_ROUTINE)(&MyClass::dummy);

C++ 클래스의 멤버 함수 signature에 클래스 이름이 붙는 것은 사실 "this" 포인터를 전달하는 함수라는 것입니다. 그래서, 엄밀히 따지면 LPTHREAD_START_ROUTINE 함수 포인터의 signature에 근접한 dummy 함수를 정의하려면 오히려 다음과 같이 해야 합니다.

class MyClass
{
public:
    DWORD __stdcall dummy() { return 0; }
};

물론, 그래도 C++ 컴파일러는 LPTHREAD_START_ROUTINE으로의 형 변환을 막습니다.

어쨌든, C++ 코드로는 this 포인터를 우아하게 전달할 수 있는 방법은 없고 단지 다음과 같이 CreateThread 함수에 this를 함께 전달하는 수밖에 없습니다.

#include "stdafx.h"
#include <Windows.h>

class MyClass
{
public:
    static DWORD WINAPI threadFunc(LPVOID ptr)
    {
        MyClass *pThis = (MyClass *)ptr;

        pThis->dummy();

        printf("threadFunc called!\n");
        return 0;
    }

    DWORD __stdcall dummy() { return 0; }
};

int main()
{
    MyClass *t = new MyClass();
    
    HANDLE hHandle = ::CreateThread(nullptr, 0, (LPTHREAD_START_ROUTINE) &MyClass::threadFunc, t, 0, nullptr);
    ::WaitForSingleObject(hHandle, -1);

    delete t;
    return 0;
}




그런데, C#에서는 어떻게 할까요?

using System;
using System.Threading;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            MyClass m = new MyClass(5);

            Thread t = new Thread(m.Test);
            t.Start();
            t.Join();
        }
    }

    class MyClass
    {
        int _value;
        public MyClass(int value) { _value = value; }

        public void Test()
        {
            Console.WriteLine("Test called: " + _value);
        }
    }
}

Thread 타입에 Test 멤버 함수를 넘겨주면서도, Test 메서드 내에서는 아무렇지도 않게 _value 멤버를 사용하고 있습니다. C++ 개발자들에게는 도저히 이해가 안 되는 코드입니다. (사실, C# 개발자 입장에서도 얼핏 생각해보면 그다지 이해가 안 됩니다.)

이에 대한 비밀은 C# 컴파일러에 있습니다. 개발자 입장에서는 "new Thread(m.Test)"라고 멤버 함수를 넣어주는 것처럼 보이지만, C# 컴파일러는 이것을 delegate 타입으로 감싼 인스턴스를 넘겨주는 부가 코드를 작성해주는 것입니다. 그래서 실제 컴파일된 코드를 .NET Reflector를 이용해 IL 코드로 보면 다음과 같은 형식으로 나옵니다.

MyClass m = new MyClass(5);

Thread t = new Thread( new ThreadStart(m, (address of)m.Test) ); // pseudo 코드입니다.

결국, Thread 클래스 내부에서는 ThreadStart 타입의 Invoke를 호출하게 되고 Invoke는 대충 다음과 같은 형식으로 처리를 하게 됩니다.

class ThreadStart
{
    object _target;
    FuncionPtr _ptrToFunction;  // pseudo 코드입니다.

    public ThreadStart(object target, FunctionPtr ptr)
    {
        _target = target;
        _ptrToFunction = ptr;
    }

    void Invoke()
    {
        _ptrToFunction(_target); // this 포인터를 넣어주고 호출
    }
}




그나저나, 전부터 참 궁금했던 내용인데요, 그토록 유연한 코딩이 가능한 C++이 왜 클래스의 함수 포인터에 대해서는 non-static의 처리를 그토록 엄격하게 처리하도록 만들었을까 하는 점입니다. 본문에서처럼 다음과 같이 강제 형 변환이 가능하다면,

LPTHREAD_START_ROUTINE pThreadFunc = (LPTHREAD_START_ROUTINE)(&MyClass::dummy);

CreateThread에 다음과 같은 식으로 전달하는 것이 가능합니다.

MyClass *t = new MyClass();
HANDLE hHandle = ::CreateThread(nullptr, 0, (LPTHREAD_START_ROUTINE) &MyClass::dummy, t, 0, nullptr);

그럼, 운영체제는 넘겨진 함수 포인터의 첫 번째 인자로 t를 전달해 줄 것이고 이로 인해 자연스럽게 this 포인터가 전달된 것처럼 동작하기 때문에 아무런 문제없이 클래스의 멤버 함수 호출이 이뤄지게 됩니다.




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

[연관 글]






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

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

비밀번호

댓글 작성자
 



2016-10-20 12시34분
[ryujh] 안녕하세요. C# 예제에서

Thread t = new Thread(m.Test);
t.Start();
t.Join();

하는 것은
m.Test(); 실행으로 생각하는 것으로 이해하고 있으며

m._value 도 this._value 로 이해하고 있는데 C#에 익숙해서 그런것인가요?

반면 C++ 코드가 이해가 어려운데 포인터 개념이 필요해서 그런 것인지요?

C#으로 웹개발만 할 수 없어서 다른 분야 개발을 알아보는데 C#을 사용하는 경우를 못찾았고 C++이 일반적이더군요.

C# 코드를 C++ 코드로 변환하면서 익히는 수 밖에 없을까요?

마지막 예제는 실제로는 실행/컴파일 불가한 코드인지요?

감사합니다.
[guest]
2016-10-20 12시55분
m.Test()를 실행하는 것은 맞지만, 얼핏 보면 MyClass의 Test 메서드를 전달하는 듯 보입니다. C++ 개발자들 입장에서는 delegate를 C++의 함수 포인터로 이해하는 경우가 많기 때문에 (실제로 그렇게 이해해도 무방하고.) this에 대한 처리가 없는 상황에서 저 코드가 잘 동작한다는 것이 의아스러운 거죠. ^^

그리고 m.Test()를 실행한다고는 하지만, 원래 내부적으로는 this 포인터를 전달해야 객체 데이터를 접근할 수 있습니다. Thread 객체가 나중에 호출해준다고 가정했을 때, "m" 인스턴스없이 m.Test()만 호출해서는 코드가 정상적으로 동작하지 않는 것이죠. (반드시 m 인스턴스를 보관하고 있어야 합니다.) 이것은 Reflection에서 MethodInfo.Invoke 메서드의 인자에 m 인스턴스가 필요한 것과 유사하다고 보시면 됩니다.

제가 제시한 C++ 코드의 핵심은 포인터인데 어렵게 느껴졌다면 그 때문이겠지요! (참고로, Visual C++ 개발자들에게는 그냥 정형화된 코드입니다.)

다른 분야라면? ^^ 오히려 C#은 웹 개발 뿐만 아니라 UI 프로그래밍에도 강점이 있습니다. Java의 경우 UI 프로그래밍이 많이 수그러든 것에 비하면 C#은 Mono를 이용한 WinForm 개발까지 포함하면 꽤나 클라이언트용 프로그램에도 좋은 이점이 있습니다.
(마지막 예제는 실행 불가입니다.)

--------------------

 CreateThread Win32 API에 C++ 클래스의 멤버 함수를 전달하는 방법
; http://www.sysnet.pe.kr/2/0/11163
정성태

... 151  152  153  [154]  155  156  157  158  159  160  161  162  163  164  165  ...
NoWriterDateCnt.TitleFile(s)
1202정성태12/21/201125977오류 유형: 144. The database '...' cannot be opened because it is version 661.
1201정성태12/14/201141047디버깅 기술: 47. .NET Reflector를 이용한 "소스 코드가 없는" 어셈블리 디버깅 [4]
1200정성태12/11/201126941디버깅 기술: 46. Windbg 확장 DLL 만들기 (2) - Debugger Extension API 사용파일 다운로드1
1199정성태12/11/201128287VC++: 55. JNI DLL 컴파일 시 x86과 x64의 Export된 함수의 이름이 왜 다를까요? [2]파일 다운로드1
1198정성태12/9/201132074디버깅 기술: 45. Windbg 확장 DLL 만들기 (1) - 스레드를 강제 종료시키는 명령어 [2]파일 다운로드1
1197정성태12/9/201129858.NET Framework: 282. Shader 강좌와 함께 배워보는 XNA Framework (2) - RenderMonkey의 Shader/Model 파일 연동파일 다운로드2
1196정성태12/9/201133051.NET Framework: 281. Shader 강좌와 함께 배워보는 XNA Framework (1) - 기초 프로그램 구조 [3]파일 다운로드2
1195정성태12/8/201147708오류 유형: 143. DXSDK_Jun10.exe 설치 시 "Error Code: S1023" 오류 해결하는 방법 [4]
1194정성태12/8/201135479개발 환경 구성: 137. Visual C++ 런타임 구성요소에 대한 디버그 버전 설치하는 방법
1193정성태12/8/201122567오류 유형: 142. Windows Phone SDK 7.1 설치 시 Expression Blend 제거를 요구하는 경우
1192정성태12/8/201125588개발 환경 구성: 136. Windows 7 SP1의 IIS에서 사용자 프로파일을 로드하는 방법
1191정성태12/6/201126672.NET Framework: 280. MVC3에서 JavaScriptSerializer 재정의하는 방법파일 다운로드1
1190정성태12/6/201129866오류 유형: 141. Visual C++ 컴파일 오류 - error C2275: 'xxxxx' : illegal use of this type as an expression [1]
1189정성태12/6/201136916VS.NET IDE: 70. Visual Studio에서 프로젝트 로드가 안된다면?
1188정성태12/3/201126039개발 환경 구성: 135. 마이크로소프트 TFS 호스팅 서비스 - Preview [3]
1187정성태12/2/201130682개발 환경 구성: 134. Robocopy 오류 및 종료 코드
1186정성태12/1/201132518.NET Framework: 279. WPF - 그리기 성능 및 Blurring 문제파일 다운로드1
1185정성태11/29/201123308.NET Framework: 278. WPF - Content의 Changed 이벤트에 해당하는게 뭔가요?파일 다운로드1
1184정성태11/29/201126096.NET Framework: 277. F#과 WPF가 어울리지 못하는 근본적인 이유 [2]
1183정성태11/26/201121600오류 유형: 140. Visual Studio 2010 - Floating된 에디트 윈도우가 사라지지 않는 경우 [2]
1182정성태11/25/201157335.NET Framework: 276. 중복 없는 숫자를 랜덤으로 배열하는 방법 [5]파일 다운로드1
1181정성태11/24/201127790디버깅 기술: 44. windbg의 mscordacwks DLL 로드 문제
1180정성태11/23/201137605.NET Framework: 275. 레지스트리 등록 및 Interop DLL 없이 COM 개체 사용하는 방법 [2]파일 다운로드1
1179정성태11/22/201128205.NET Framework: 274. ReaderWriterLockSlim은 언제 쓰는 걸까요? [4]파일 다운로드1
1178정성태11/19/201124690.NET Framework: 273. 설치된 .NET 버전에 민감한 코드를 포함하는 경우, 다중으로 어셈블리를 만들어야 할까요?파일 다운로드1
1177정성태11/18/201129953.NET Framework: 272. 소켓 연결 시간 제한 - 두 번째 이야기 [1]파일 다운로드1
... 151  152  153  [154]  155  156  157  158  159  160  161  162  163  164  165  ...