Microsoft MVP성태의 닷넷 이야기
닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock [링크 복사], [링크+제목 복사],
조회: 2690
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 3개 있습니다.)
디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
; https://www.sysnet.pe.kr/2/0/11268

닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
; https://www.sysnet.pe.kr/2/0/13552

닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
; https://www.sysnet.pe.kr/2/0/13553




windbg - Monitor.Enter의 thin lock과 fat lock

마침 아래와 같은 좋은 글이 있어,

Managed object internals, Part 2. Object header layout and the cost of locking
; https://devblogs.microsoft.com/premier-developer/managed-object-internals-part-2-object-header-layout-and-the-cost-of-locking/

Sync Block Index (SBI) \ Object Header Word
; https://yonifedaeli.blogspot.com/2017/03/sync-block-index-sbi-object-header-word.html

소개하려고 합니다. (그대로 베낍니다. ^^)




예를 들어, 다음과 같이 코드를 작성 후,

using System.Threading;

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            object o = new object();
            lock (o)
            {
                Debugger.Break();
            }
        }
    }
}

windbg를 이용해 실행한 다음 (처음 한 번은 'g' 키를 눌러 진행해) Debugger.Break에서 멈추었을 때 thinlock 상태를 확인할 수 있습니다.

0:000> !dumpheap -thinlock
         Address               MT     Size
000001d125c02e38 00007fffea220b08       24 ThinLock owner 1 (000001d1241a2970) Recursive 0
Found 1 objects.

0:000> !DumpObj /d 000001d125c02e38
Name:        System.Object
MethodTable: 00007fffea220b08
EEClass:     00007fffea1d48f0
Size:        24(0x18) bytes
File:        C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Object
Fields:
None
ThinLock owner 1 (000001d1241a2970), Recursive 0

thinlock 상태에서는 별도의 SyncBlock이 생성되지 않으므로 sos의 syncblk 명령어를 사용하면 비어있는 것을 볼 수 있습니다.

0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
-----------------------------
Total           0
CCW             0
RCW             0
ComClassFactory 0
Free            0

즉, thinlock은 lock이 경합을 벌이지 않는 상태라면 성능을 위해 별도의 SyncBlock을 생성하지 않고 Object Header 내에만 정보를 유지하는 단계인 것입니다. 실제로 이 상태의 해당 object, 위의 소스코드에서는 "o" 인스턴스를 확인해 보면,

0:000> dq 000001d125c02e38-8 L3
000001d1`25c02e30  00000001`00000000 00007fff`ea220b08
000001d1`25c02e40  00000000`00000000

하위 값이 0x00000001로 나오는데, 이 상태의 의미를 확인해 보면,

0000 0000 0000 0000 0000 0000 0000 0001
|||| ||- BIT_SBLK_IS_HASHCODE
|||| |- BLT_SBLK_IS_HASH_OR_SYNCBLOCKINDEX
||||-BIT_SBLK_SPIN_LOCK
|||- BIT_SBLK_GC_RESERVE
||- BIT_SBLK_FINALIZER_RUN
|- BIT_SBLK_AGILE_IN_PROGRESS

[이미지 출처: "Managed object internals, Part 2. Object header layout and the cost of locking"]
object_header_syncblk_0.png

0~10비트: thread id that’s holding the lock

[이미지 출처: "Managed object internals, Part 2. Object header layout and the cost of locking"]
object_header_syncblk_1.png

해당 lock을 소유하고 있는 스레드 ID가 1로 나오는데 이를 !threads로 알아낼 수 있습니다.

0:009> !threads
ThreadCount:      4
UnstartedThread:  0
BackgroundThread: 3
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                                                                                        Lock  
       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
   0    1 cfa0 000001d1241a2970  202a020 Preemptive  0000025ECD2A65C8:0000025ECD2A7FD0 0000025ecb632c70 0     MTA 
   5    2 bf60 0000015ecb6bcf90    2b220 Preemptive  0000000000000000:0000000000000000 0000025ecb632c70 0     MTA (Finalizer) 

따라서, 특정 lock이 thinlock 상태라면 1) 한 번도 다른 스레드에서 lock 경합을 벌인 적이 없거나, 2) 경합을 벌였어도 일정 spin 타임 내에 있는 경우가 됩니다. (이 외에도, GetHashCode를 부른 적이 없어야 합니다.)

자, 그럼 일부러 경합을 벌여보면,

static void Main(string[] args)
{
    object o = new object();
    lock (o)
    {
        Task.Run(() =>
        {
            // This will promote a thin lock as well
            lock (o) { }
        });

        // 10 ms is not enough, the CLR spins longer than 10 ms.
        Thread.Sleep(100);
        Debugger.Break();
    }
}

이제는 syncblk이 생성된 것을 볼 수 있고,

0:009> !dumpheap -thinlock
         Address               MT     Size
Found 0 objects.

0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
    6 000002de0f4a8838            3         1 000002de0f452980 7e48   0   000002de10f52e50 System.Object
-----------------------------
Total           6
CCW             1
RCW             2
ComClassFactory 0
Free            0

인스턴스 'o'에 대해 Object Header를 조사해 보면,

0:000> dq 000002de10f52e50-8 L3
000002de`10f52e48  08000006`00000000 00007fff`ea220b08
000002de`10f52e58  00000000`00000000

0x08000006
0000 1000 0000 0000 0000 0000 0000 0110
|||| ||- BIT_SBLK_IS_HASHCODE
|||| |- BLT_SBLK_IS_HASH_OR_SYNCBLOCKINDEX (== 0x08000000)
||||-BIT_SBLK_SPIN_LOCK
|||- BIT_SBLK_GC_RESERVE
||- BIT_SBLK_FINALIZER_RUN
|- BIT_SBLK_AGILE_IN_PROGRESS

[이미지 출처: "Managed object internals, Part 2. Object header layout and the cost of locking"]
object_header_syncblk_2.png

BLT_SBLK_IS_HASH_OR_SYNCBLOCKINDEX 플래그가 1로 설정돼 있으므로 이하 (BIT_SBLK_IS_HASHCODE를 제외한) 0~25 비트의 값이 Sync Block에 대한 인덱스를 가리키게 됩니다. 위의 경우 그 값은 6이고, !syncblk 명령어의 결과에 있는 Index 값에 정확히 일치합니다.




참고로, 예전에 썼던 글의 내용에서,

windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
; https://www.sysnet.pe.kr/2/0/11268

lock을 대기 중인 스레드의 kv 결과로 어떤 SyncBlock에 걸려 있는지를 알아낼 수 있다고 했는데요, 이번에 다시 해보니,

0:009> kv
 # Child-SP          RetAddr               : Args to Child                                                           : Call Site
00 000000f4`222fe5b8 00007ff8`0a08f6f9     : 000002de`296fa3d0 000002de`296fa3e0 000002de`0f3c0000 00007ff8`0c9f6f52 : ntdll!NtWaitForMultipleObjects+0x14
01 000000f4`222fe5c0 00007fff`f0311636     : 00000000`00000000 00007fff`00000000 00000000`ffffffff 000002de`0f4a8850 : KERNELBASE!WaitForMultipleObjectsEx+0xe9
02 000000f4`222fe8a0 00007fff`f031102a     : 00000000`00000001 00000000`00000001 00000000`00000000 00007ff8`0c92ab11 : clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x62
03 000000f4`222fe900 00007fff`f0310e01     : 00007fff`00000001 00007fff`00000001 00000000`00000001 00007fff`00000000 : clr!Thread::DoAppropriateWaitWorker+0x206
04 000000f4`222fe9f0 00007fff`f0283157     : 000002de`0f4a8850 00000000`00000001 000002de`0f4a8838 000002de`10f52e00 : clr!Thread::DoAppropriateWait+0x7d
05 000000f4`222fea70 00007fff`f06d93ee     : 000000f4`222fedf0 00000000`00000000 000002de`296f3860 00007fff`ea221740 : clr!CLREventBase::WaitEx+0xab
06 000000f4`222feae0 00007fff`f06d92a2     : 000002de`0f4a8838 00007fff`f02c735b 000002de`0f4a8838 000002de`10f52e50 : clr!AwareLock::EnterEpilogHelper+0x11a
07 000000f4`222feba0 00007fff`f05ee5a9     : 000002de`296f3860 000002de`0f4a8838 00000000`00000000 000000f4`222fedf0 : clr!AwareLock::EnterEpilog+0x5a
...[생략]...

CLREventBase::WaitEx에는 값이 안 나오고, AwareLock::EnterEpilogHelper 등의 "Args to Child"에서 확인할 수 있었습니다. (이 값은 닷넷 패치 버전에 따라서도 달라질 수 있기 때문에 항상 그렇다고 가정해서는 안 됩니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/14/2024]

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

비밀번호

댓글 작성자
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13572정성태3/4/20242848닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/20242633닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/20242401닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/20242317닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20242421닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/20242349오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20242449오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20242301닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20242653Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20242701디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20242601오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20242827닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20242758디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20243578오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242860닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20242535Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20242650Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242989닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20242616VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20242649닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20242690닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20243001닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20243221Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20243513개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20243212개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242974개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...