C# - Lock / Wait 상태에서도 STA COM 메서드 호출 처리
결론 먼저 말하면, 이번 글의 내용도 전체적인 원칙은 지난 글에 설명한 내용과 같습니다.
C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리
; https://www.sysnet.pe.kr/2/0/13688
즉, Lock / Wait 상태에서 허용되는 메시지 펌핑의 처리에 COM 메서드 호출도 포함돼 있는 것입니다.
그래도 직접 확인해 보면 더 재미있을 것 같습니다. ^^ 예제 구성은 지난 글에 설명한 대로 (레지스트리를 어지럽히지 않기 위해) reg-free로 COM 개체를 참조하는 Windows Forms C# 프로젝트를 만들었습니다.
Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법
; https://www.sysnet.pe.kr/2/0/13693
해당 예제 구성에서 ATL 프로젝트의 COM 함수인 HelloWorld만 Thread ID를 함께 출력하도록 변경합니다.
STDMETHODIMP CATLSimpleObject::HelloWorld(BSTR text)
{
wchar_t buffer[1024] = { 0 };
swprintf(buffer, 1024, L"[tid: %d] %s HelloWorld\n", GetCurrentThreadId(), text);
::OutputDebugStringW(buffer);
printf("%S\n", buffer);
return S_OK;
}
자, 그럼 메시지 루프가 있는 WinForms 예제를 통해 알아보기 전에, 메시지 루프가 없는 콘솔 예제로 기본적인 동작을 확인해 보겠습니다. 우선, ATL 프로젝트에서 만든 COM 개체가 STA 유형이기 때문에 다음과 같이 호출할 수 있습니다.
internal class Program
{
[DllImport("kernel32.dll")]
public static extern uint GetCurrentThreadId();
[STAThread]
static void Main(string[] args)
{
Console.WriteLine($"Console ThreadID: {GetCurrentThreadId()}"); // Console ThreadID: 67196
ATLProject1Lib.ATLSimpleObjectClass _obj = new ATLProject1Lib.ATLSimpleObjectClass();
_obj.HelloWorld($"from Main thread"); // 출력 결과: [tid: 67196] from Main thread HelloWorld
}
}
보는 바와 같이 STA COM 개체를 STA 유형의 스레드에서 생성했으므로, 해당 스레드에서는 별도의 마샬링 작업 없이 곧바로 호출이 가능합니다. 그래서 출력에 나온 스레드 ID가 2개 모두 67196으로 같습니다.
이제 위의 예제에서, _obj 개체를 다른 스레드에 전달해 호출해 보겠습니다.
[STAThread]
static void Main(string[] args)
{
Console.WriteLine($"Console ThreadID: {GetCurrentThreadId()}");
ATLProject1Lib.ATLSimpleObjectClass _obj = new ATLProject1Lib.ATLSimpleObjectClass();
new Thread(() =>
{
ATLProject1Lib.ATLSimpleObjectClass marshalled = _obj;
marshalled.HelloWorld($"from another thread");
})
{
IsBackground = true
}.Start();
_obj.HelloWorld($"from Main thread");
Console.ReadLine();
}
위와 같이 변경하고 실행해 보면,
Console ThreadID: 57504
[tid: 57504] from Main thread HelloWorld
출력 결과에 "from another thread" 문구는 보이지 않습니다. 왜냐하면, STA COM 개체는 그 COM 개체를 생성한 스레드에서만 메서드 호출 처리를 할 수 있기 때문입니다. 위와 같이 다른 스레드에서 호출하려는 경우에는 마샬링을 거쳐 호출이 되는데요, 그 호출의 직렬화를 위해 사용되는 것이 메시지 루프입니다. 하지만, 위의 Console App은 COM 개체를 생성한 스레드에 메시지 루프가 없기 때문에 새로운 스레드에서의 HelloWorld 메서드 호출이 처리가 안 됩니다. 결국, 새로운 스레드는 저 호출에서 Blocking이 걸리기 때문에 영원히 종료하지 않게 됩니다.
그나저나, 저 코드가 C#이기 때문에 쉽게 작성됐지만 C/C++이었다면
CoMarshalInterThreadInterfaceInStream Win32 API를 이용해 인터페이스를 Stream으로 마샬링한 다음, 다른 스레드에서
CoGetInterfaceAndReleaseStream을 호출해 언마샬링을 해야 합니다. 아마도 이제는 이런 함수를 기억하실 분들이 거의 없는 시기가 되었지만. ^^
What is COM marshaling and how do I use it?
; https://devblogs.microsoft.com/oldnewthing/20151020-00/?p=91321
What are the rules for CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream?
; https://devblogs.microsoft.com/oldnewthing/20151021-00/?p=91311
What are the rules for CoMarshalInterface and CoUnmarshalInterface?
; https://devblogs.microsoft.com/oldnewthing/20151022-00/?p=91301
CoGetInterfaceAndReleaseStream does not mix with smart pointers
; https://devblogs.microsoft.com/oldnewthing/20151023-00/?p=91291
결국, 새로운 스레드의 Blocking을 풀어내려면 STA COM 개체를 생성한 측에서 메시지 루프를 돌려야 합니다. 즉, 다른 스레드에서 받은 HelloWorld 호출 신호를 STA Thread가 받아서 호출을 해주는 것입니다.
따라서, 위의 예제를 그대로 Windows Forms로 가져가면,
using System.Runtime.InteropServices;
namespace WinFormsApp1;
public partial class Form1 : Form
{
[DllImport("kernel32.dll")]
public static extern uint GetCurrentThreadId();
public Form1()
{
InitializeComponent();
}
ATLProject1Lib.ATLSimpleObjectClass _obj = new ATLProject1Lib.ATLSimpleObjectClass();
private void Form1_Load(object sender, EventArgs e)
{
System.Diagnostics.Trace.WriteLine($"Form1 ThreadID: {GetCurrentThreadId()}");
_obj.HelloWorld("from UI thread");
new Thread(() =>
{
ATLProject1Lib.ATLSimpleObjectClass marshalled = _obj;
marshalled.HelloWorld("from another thread");
})
{ IsBackground = true }.Start();
}
}
Visual Studio에서 F5 디버깅으로 실행했을 때 Output 창에는 이런 출력 결과가 나옵니다.
...[생략]...
Form1 ThreadID: 73232
[tid: 73232] from UI thread HelloWorld
...[생략]...
[tid: 73232] from another thread HelloWorld
메시지 루프가 있기 때문에 COM 개체를 직접 생성하지 않았던 스레드에서의 호출도 정상적으로 처리되었습니다. 게다가 ThreadID도 모두 같은 73232로 나옵니다.
여기까지 테스트 결과가 잘 이해되시죠? ^^
자, 그럼 lock 상황으로 가보겠습니다. lock으로 인해 UI 스레드를 blocking 하는 코드를 다음과 같이 추가하고,
ATLProject1Lib.ATLSimpleObjectClass _obj = new ATLProject1Lib.ATLSimpleObjectClass();
object _objLock = new object();
private void Form1_Load(object sender, EventArgs e)
{
System.Diagnostics.Trace.WriteLine($"Form1 ThreadID: {GetCurrentThreadId()}");
_obj.HelloWorld("from UI thread");
new Thread(() =>
{
ATLProject1Lib.ATLSimpleObjectClass marshalled = _obj;
lock (_objLock)
{
while (true)
{
marshalled.HelloWorld("from another thread");
Thread.Sleep(3000);
}
}
})
{ IsBackground = true }.Start();
}
private void button1_Click(object sender, EventArgs e)
{
_obj.HelloWorld("UI Thread");
lock (_objLock)
{
System.Diagnostics.Trace.WriteLine("Never see this message in the output window");
}
}
만약,
지난번("C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리") 글의 테스트처럼 lock 상태에서 COM 개체 호출을 가능하게 했다면 위에서 "button1"을 눌렀어도 new Thread 내부의 while 루프는 정상적으로 HelloWorld를 계속 부를 수 있어야 합니다.
다행히 기대했던 대로, F5 실행해 보면 Output 창에는 "[tid: ...] from another thread HelloWorld" 메시지가 출력됩니다. 반면, lock 대신 "Thread.Sleep(-1)"으로 바꾸면,
private void button1_Click(object sender, EventArgs e)
{
Thread.Sleep(-1);
}
lock의 잠금 상태에서와는 달리 "button1"을 누른 경우 이제 더 이상 Output 화면에는 "from another thread HelloWorld" 메시지가 출력되지 않습니다.
이걸로 확인 끝!!! ^^
(
첨부 파일은 이 글의 예제 프로젝트를 포함합니다.)
위의 글을 읽고 아래의 Q&A를 보시면 이해가 더 잘 될 것입니다.
Which blocking operations cause an STA thread to pump COM messages?
; https://stackoverflow.com/questions/21571598/which-blocking-operations-cause-an-sta-thread-to-pump-com-messages
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]