ManagedThreadId ?
미리 말씀드리자면, 이번 토픽은 아래의 토픽에 대한 부연 설명 차원에서 쓰는 것입니다.
스레드(thread)의 시작
; http://www.bangsil.pe.kr/board/read.aspx?BoardId=da05ba1b-3e9b-4d16-b8f8-ff2e4f7514c5&PostId=1cc5b053-77a3-46cb-8cdf-345b04e214d7
개인적으로, 가끔 다른 분들이 쓴 이야기를 이렇게 이어서 쓰는 경우가 있는데요. 어차피 저도 그에 대한 토픽을 쓰려면 참조한 해당 토픽을 쓴 분과 비슷한 양의 글을 써야 하거나, 아니면, 해당 토픽의 댓글로 달아둘 수도 있겠는데, 그런 경우에는 애써 쓴 이야기가 댓글 수준으로 묻히는 것이 아깝기 때문에. ^^
그런 저런 이유로 이렇게 릴레이 토픽을 쓰는 것이니 감안해 주십시오. ^^
제가 부연 설명할 것은, 위의 토픽 중간에 나온 다음의 이야기입니다.
(2022-04-07 업데이트: 아래의 글은 닷넷 프레임워크 환경에서만 유효하고, .NET Core/5+에서는 ManagedThreadId와 AppDomain.GetCurrentThreadId의 값이 같습니다. 참고 -
닷넷 런타임에 따라 달라지는 AppDomain.GetCurrentThreadId의 반환값)
원 글을 쓰신 분이 설명한 대로, 일단 "값이 다른 것"은 맞지만 이유에 대한 설명은 좀 안 맞는 것 같습니다. ^^
잘 알려지지 않았지만, CLR은 상당한 유연성을 갖고 설계되었습니다. 2.0에 와서는 더더욱 그러한 설계가 반영이 되어서 호스팅 환경을 자유롭게 구성할 수 있도록 하고 있습니다. 이쯤에서... 감을 잡으신 분이 계실래나? ^^
그렇습니다. CLR 호스팅의 유연성은 스레드 사용에 대한 사용자 정의도 가능하게 하고 있습니다. 따라서, 호스팅 코드를 어떻게 만드느냐에 따라서, .NET 응용 프로그램의 "논리적인" 스레드 사용이 실제 물리적인 Native 스레드와 1:1 매핑이 될 수도 있고, 아니면 Native 스레드 위에서 사용자 정의되는 경량화된 스레드(Fiber)와 매핑이 될 수도 있습니다. 오호... 답이 나왔습니다. ^^
Fiber와 .NET Managed Thread가 매핑이 되는 경우, Native 스레드의 ID를 반환하는 AppDomain.GetCurrentThreadId 메서드를 사용하게 되면, 서로 다른 Managed Thread 임에도 불구하고 동일한 값을 반환하게 되기 때문에 문제의 소지가 있습니다. 따라서, 그런 경우를 위해 고안된 것이 바로 "Managed Thread ID"입니다.
그렇다면... 과연 Fiber로 Managed Thread가 구현된 호스팅 환경이 구현된 예가 있을까요?
다행히도(?) 아직은 없습니다. 있을 뻔한 적은 있었습니다. 과거 SQL Server 2005에 사용될 SQLClr 호스팅 환경에서 최대한의 성능 개선을 위해 Fiber가 고려된 적이 있었습니다. 고려 수준이 아니라, 실제로 구현이 진행되기도 했습니다. 관련해서는 다음의 토픽에서 그 구현을 엿볼 수 있습니다.
Cooperative Fiber Mode Sample - Day 11
; https://learn.microsoft.com/en-us/archive/blogs/dinoviehland/cooperative-fiber-mode-sample-day-11
하지만, 곧 이 기능은 RTM 즈음에서 취소되었습니다.
Fiber mode gone for SQLCLR
; https://roberthurlbut.com/blog/fiber-mode-gone-for-sqlclr
현재 여러 제품에서 호스팅 되고 있는 (Internet Explorer, SQL Server, .NET App 등...) CLR 중에는 Fiber를 사용하는 CLR 호스팅은 존재하지 않습니다. 하지만, Microsoft가 GetCurrentThreadId를 "Obsolete" 특성을 준 데에는 향후에 나올 어느 환경에 대한 CLR 호스팅 환경에는 Fiber를 도입할 수도 있음을 시사하기 때문에 만약 여러분들이 GetCurrentThreadId를 사용했다면 다른 CLR 호스팅 환경으로 갈 때 주의해야 할 필요가 있습니다.
어쩌면, 지금도 어느 3rd-party에서인가는, 자신들이 만드는 특수한 응용 프로그램을 위해서 CLR 호스팅 환경을 커스터마이징 하고 있을 지도 모르겠습니다. 물론... 여러분도 Fiber를 쓰는 CLR 호스팅 환경을 제작할 수 있음은 당연하고. ^^
[내용 추가: 2007-05-30]
예전 MSDN Magazine의 특정 칼럼에 대한 질문을 한 번 해서 답변을 받았던 적이 있는 John Robbins에게 "관리 스레드"와 "OS 스레드"에 관한 의견을 좀 구했는데,,, 다음과 같이 메일이 왔습니다. (물론, CLR Team에게 물어보는 것이 가장 확실했겠지만.)
What follows is simply my understanding of how threads work in the CLR environment. Microsoft developers on the CLR team are the ones who can give you the real answer.
Today in Microsoft's CLR implementation, a .NET thread maps directly to a native thread. Thus, the OS thread id is unique per .NET thread. My understanding is that the CLR team didn't want people to rely on that implementation staying consistent forever. Consequently, Microsoft has always said not to assume that because they could change the threading model in the future. The Windows thread scheduler is a great piece of code and has been tuned and tested extensively for twenty years. While you can use fibers, which were put in the OS to assist with porting applications from UNIX that implemented their own threading packages, you're required to implement all the scheduling on your own. My
*opinion* (and only my opinion so don't take this as any official statement from Microsoft) is that to go off and implement your own thread scheduler would be a huge wasted effort so the CLR team will continue to map managed threads to native threads. You're comments about using TLS and the windows API are correct. Again, moving to a fibers implementation would require the CLR to hook many API functions to ensure they work. That would be very easy to mess up and introduce numerous compatibility problems.
There's my opinion.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]