성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] 아쉽게도, 커뮤니티는 아니고 개인 블로그입니다. ^^
[정성태] 질문이 잘 이해가 안 됩니다. 우선, 해당 소스코드에서 ILis...
[양승조
] var대신 dinamic으로 선언해서 해결은 했습니다. 맞는 해...
[양승조
] 또 막혔습니다. ㅠㅠ var list = props[i].Ge...
[양승조
] 아. 감사합니다. 어제는 안됐던것 같은데....정신을 차려야겠네...
[정성태] "props[i].GetValue(props[i])" 코드에서 ...
[정성태] 저렇게 조각 코드 말고, 실제로 재현이 되는 예제 프로젝트를 압...
[정성태] Modules 창(Ctrl+Shift+U)을 띄워서, 해당 Op...
[정성태] 만드실 수 있습니다. 단지, Unity 엔진 내의 스크립트와 W...
[공진영] 안녕하세요 좋은글 감사합니다. 현재 제가 wpf로 관제 모...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<div style='display: inline'> <br /> <div class='mainCenterTitle'>ManagedThreadId ?</div><br /> <br /> 미리 말씀드리자면, 이번 토픽은 아래의 토픽에 대한 부연 설명 차원에서 쓰는 것입니다.<br /> <br /> <pre class='code'> 스레드(thread)의 시작 ; http://www.bangsil.pe.kr/board/read.aspx?BoardId=da05ba1b-3e9b-4d16-b8f8-ff2e4f7514c5&PostId=1cc5b053-77a3-46cb-8cdf-345b04e214d7 </pre> <br /> 개인적으로, 가끔 다른 분들이 쓴 이야기를 이렇게 이어서 쓰는 경우가 있는데요. 어차피 저도 그에 대한 토픽을 쓰려면 참조한 해당 토픽을 쓴 분과 비슷한 양의 글을 써야 하거나, 아니면, 해당 토픽의 댓글로 달아둘 수도 있겠는데, 그런 경우에는 애써 쓴 이야기가 댓글 수준으로 묻히는 것이 아깝기 때문에. ^^<br /> <br /> 그런 저런 이유로 이렇게 릴레이 토픽을 쓰는 것이니 감안해 주십시오. ^^<br /> <br /> <hr style='width: 50%' /><br /> <br /> 제가 부연 설명할 것은, 위의 토픽 중간에 나온 다음의 이야기입니다.<br /> <br /> (2022-04-07 업데이트: 아래의 글은 닷넷 프레임워크 환경에서만 유효하고, .NET Core/5+에서는 ManagedThreadId와 AppDomain.GetCurrentThreadId의 값이 같습니다. 참고 - <a target='tab' href='https://www.sysnet.pe.kr/2/0/13024'>닷넷 런타임에 따라 달라지는 AppDomain.GetCurrentThreadId의 반환값</a>)<br /> <br /> <span class='comment'> <a target='tab' href='https://learn.microsoft.com/en-us/dotnet/api/system.threading.thread.managedthreadid'>Thread.CurrentThread.ManagedThreadId</a>와 <a target='tab' href='https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadid'>AppDomain.GetCurrentThreadId()</a>의 값이 다른 이유는 이렇다.<br /> <br /> 전자의 경우 .NET 2.0에서 새로 생긴 프로퍼티인데 이는 관리되는 스레드의 고유한 아이디가 항상 변하는 점을 보완한 프로퍼티이다.<br /> 위 코드를 몇 번이고 컴파일 해 보라.<br /> 위의 결과값에서 1과 3이라는 숫자는 바뀌지 않으며 1304와 3132는 항상 바뀔 것이다.<br /> <br /> 고로 후자의 메서드는 이제 더 이상 사용하지 않는다.<br /> <br /> [ObsoleteAttribute("AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). <br /> To get a stable identifier for a managed thread, use the ManagedThreadId property on Thread. <br /> <a target='_tab' href='https://learn.microsoft.com/en-us/previous-versions/aa497287(v=msdn.10)'>http://go.microsoft.com/fwlink/?linkid=14202</a>", false)] <br /> public static int GetCurrentThreadId ()<br /> </span><br /><br /> <br /> 원 글을 쓰신 분이 설명한 대로, 일단 "값이 다른 것"은 맞지만 이유에 대한 설명은 좀 안 맞는 것 같습니다. ^^<br /> <br /> <hr style='width: 50%' /><br /> <br /> 잘 알려지지 않았지만, CLR은 상당한 유연성을 갖고 설계되었습니다. 2.0에 와서는 더더욱 그러한 설계가 반영이 되어서 호스팅 환경을 자유롭게 구성할 수 있도록 하고 있습니다. 이쯤에서... 감을 잡으신 분이 계실래나? ^^<br /> <br /> 그렇습니다. CLR 호스팅의 유연성은 스레드 사용에 대한 사용자 정의도 가능하게 하고 있습니다. 따라서, 호스팅 코드를 어떻게 만드느냐에 따라서, .NET 응용 프로그램의 "논리적인" 스레드 사용이 실제 물리적인 Native 스레드와 1:1 매핑이 될 수도 있고, 아니면 Native 스레드 위에서 사용자 정의되는 경량화된 스레드(Fiber)와 매핑이 될 수도 있습니다. 오호... 답이 나왔습니다. ^^<br /> <br /> Fiber와 .NET Managed Thread가 매핑이 되는 경우, Native 스레드의 ID를 반환하는 AppDomain.GetCurrentThreadId 메서드를 사용하게 되면, 서로 다른 Managed Thread 임에도 불구하고 동일한 값을 반환하게 되기 때문에 문제의 소지가 있습니다. 따라서, 그런 경우를 위해 고안된 것이 바로 "Managed Thread ID"입니다.<br /> <br /> 그렇다면... 과연 Fiber로 Managed Thread가 구현된 호스팅 환경이 구현된 예가 있을까요?<br /> <br /> 다행히도(?) 아직은 없습니다. 있을 뻔한 적은 있었습니다. 과거 SQL Server 2005에 사용될 SQLClr 호스팅 환경에서 최대한의 성능 개선을 위해 Fiber가 고려된 적이 있었습니다. 고려 수준이 아니라, 실제로 구현이 진행되기도 했습니다. 관련해서는 다음의 토픽에서 그 구현을 엿볼 수 있습니다.<br /> <br /> <pre class='code'> Cooperative Fiber Mode Sample - Day 11 ; <a href='https://learn.microsoft.com/en-us/archive/blogs/dinoviehland/cooperative-fiber-mode-sample-day-11'>https://learn.microsoft.com/en-us/archive/blogs/dinoviehland/cooperative-fiber-mode-sample-day-11</a> </pre> <br /> 하지만, 곧 이 기능은 RTM 즈음에서 취소되었습니다.<br /> <br /> <pre class='code'> Fiber mode gone for SQLCLR ; <a target='_tab' href='https://roberthurlbut.com/blog/fiber-mode-gone-for-sqlclr'>https://roberthurlbut.com/blog/fiber-mode-gone-for-sqlclr</a> </pre> <br /> <hr style='width: 50%' /><br /> <br /> 현재 여러 제품에서 호스팅 되고 있는 (Internet Explorer, SQL Server, .NET App 등...) CLR 중에는 Fiber를 사용하는 CLR 호스팅은 존재하지 않습니다. 하지만, Microsoft가 GetCurrentThreadId를 "Obsolete" 특성을 준 데에는 향후에 나올 어느 환경에 대한 CLR 호스팅 환경에는 Fiber를 도입할 수도 있음을 시사하기 때문에 만약 여러분들이 GetCurrentThreadId를 사용했다면 다른 CLR 호스팅 환경으로 갈 때 주의해야 할 필요가 있습니다.<br /> <br /> 어쩌면, 지금도 어느 3rd-party에서인가는, 자신들이 만드는 특수한 응용 프로그램을 위해서 CLR 호스팅 환경을 커스터마이징 하고 있을 지도 모르겠습니다. 물론... 여러분도 Fiber를 쓰는 CLR 호스팅 환경을 제작할 수 있음은 당연하고. ^^<br /> <br /> <br /> <hr /> [내용 추가: 2007-05-30]<br /> 예전 MSDN Magazine의 특정 칼럼에 대한 질문을 한 번 해서 답변을 받았던 적이 있는 John Robbins에게 "관리 스레드"와 "OS 스레드"에 관한 의견을 좀 구했는데,,, 다음과 같이 메일이 왔습니다. (물론, CLR Team에게 물어보는 것이 가장 확실했겠지만.)<br /> <br /> 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.<br /> <br /> 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<br /> *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.<br /> <br /> There's my opinion. <br /> <br /> <br /><br /><hr /><span style='color: Maroon'>[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]</span> </div>
첨부파일
스팸 방지용 인증 번호
1477
(왼쪽의 숫자를 입력해야 합니다.)