http://blog.naver.com/techshare/100143625141
위의 링크에서 퍼온 글입니다. 쩝 c#에서 포인터 쓰는건 좀 낯설은데 ^^
어려운 windbg 를 사용하지 않아도 C# 에서 간단하게 unsafe/fixed 를 이용하여 확인을 하는 것도 가능합니다.
어떻게 그럴 수 있는지 ^^ 배열부터 시험삼아서 테스트를 해볼까요? ".NET Array는 왜 12 bytes 의 기본 메모리를 점유할까?"글에서 primitive 타입의 배열은 다음과 같은 구조를 갖는다고 설명했었습니다.
위의 값을 구해오기 위해서, C# 으로는 다음과 같이 코딩을 할 수 있습니다.
만약, test 인스턴스에 대해 lock 구문을 걸면 SyncBlock Index 이 변경된 것을 확인할 수 있습니다.
출력된 0x72fd28b8 값이 MethodTable 주소값인지 확인하려면 windbg를 사용하여 !dumpobj 명령어를 실행해야만 하는데, 실제로 해보시면 값이 맞다는 것을 알 수 있습니다.
그 다음, 일반 참조 개체의 인스턴스 메모리를 살펴볼 차례인데요. 아쉽게도 object 형 개체에 대해서는 직접적으로 포인터를 받아올 수 없고 다음과 같이 해당 개체에 정의된 필드의 주소를 가져오는 방식을 사용하여 우회할 수 있습니다.
지금까지 살펴본 코드에 착안해서 ^^ 현실성은 다소 떨어지지만... 재미있는 실험을 하나 해볼까요? ^^
다음은, 무한 대기 상태로 빠지는 예제입니다.
그런데, 다음과 같이 강제로 SyncBlock Index 값을 설정/해제하는 코드를 작성하고,
LockThread 에서 lock 을 얻는 앞 뒤로 다음과 같이 처리를 해주면,
^^ 정상적으로 lock 을 얻는 것을 확인할 수 있습니다. 참고로, ForceSetLock 을 호출하지 않는 경우 - 즉, 나중에 SyncBlock index 값을 돌려놓지 않으면 t1.Join() 함수에서 다음과 같은 예외가 발생합니다.
암튼... 재미있는 탐구였지요? ^^
(첨부된 파일은 위의 코드를 포함한 예제 프로젝트입니다.)
참 재밌네요 ㅋㅋㅋ
위의 링크에서 퍼온 글입니다. 쩝 c#에서 포인터 쓰는건 좀 낯설은데 ^^
지난 글에서, 배열과 일반 참조형에 대한 관리 힙의 인스턴스 구조를 살펴보았는데요.
일반 참조형의 기본 메모리 소비는 얼마나 될까요? ; http://www.sysnet.pe.kr/2/0/1174 .NET Array는 왜 12 bytes 의 기본 메모리를 점유할까? ; http://www.sysnet.pe.kr/2/0/1173 .NET 참조 개체 인스턴스의 SyncBlock 을 확인하는 방법 ; http://www.sysnet.pe.kr/2/0/1175
어려운 windbg 를 사용하지 않아도 C# 에서 간단하게 unsafe/fixed 를 이용하여 확인을 하는 것도 가능합니다.
어떻게 그럴 수 있는지 ^^ 배열부터 시험삼아서 테스트를 해볼까요? ".NET Array는 왜 12 bytes 의 기본 메모리를 점유할까?"글에서 primitive 타입의 배열은 다음과 같은 구조를 갖는다고 설명했었습니다.
-4 : SyncBlock Index +0 : MethodTable Address +4 : 배열 요소 크기 +8 ~ : 값 배열 마지막 배열의 다음 4 byte - unknown field : 0x0
위의 값을 구해오기 위해서, C# 으로는 다음과 같이 코딩을 할 수 있습니다.
static unsafe void Main(string[] args) { int [] test = new int[1]; test[0] = 0xff; Console.WriteLine("int [] ================== "); fixed (int *p1 = &test[0]) { Console.WriteLine("SyncBlock Index: " + (*(p1 - 3)).ToString("x")); Console.WriteLine("MethodTable Address: " + (*(p1 - 2)).ToString("x")); Console.WriteLine("배열 요소 크기: " + (*(p1 - 1)).ToString("x")); Console.WriteLine("0번째 배열 값: " + (*(p1 - 0)).ToString("x")); Console.WriteLine("[unknown field]: " + (*(p1 + 1)).ToString("x")); } } // 출력 결과 SyncBlock Index: 0 MethodTable Address: 72fd28b8 배열 요소 크기: 1 0번째 배열 값: ff [unknown field]: 0
만약, test 인스턴스에 대해 lock 구문을 걸면 SyncBlock Index 이 변경된 것을 확인할 수 있습니다.
Console.WriteLine("locked int [] ================== "); lock (test) { fixed (int* p1 = &test[0]) { Console.WriteLine("SyncBlock Index: " + (*(p1 - 3)).ToString("x")); ...[생략]... } } // 출력 결과 SyncBlock Index: 1
출력된 0x72fd28b8 값이 MethodTable 주소값인지 확인하려면 windbg를 사용하여 !dumpobj 명령어를 실행해야만 하는데, 실제로 해보시면 값이 맞다는 것을 알 수 있습니다.
그 다음, 일반 참조 개체의 인스턴스 메모리를 살펴볼 차례인데요. 아쉽게도 object 형 개체에 대해서는 직접적으로 포인터를 받아올 수 없고 다음과 같이 해당 개체에 정의된 필드의 주소를 가져오는 방식을 사용하여 우회할 수 있습니다.
class Program { public int value = 0xff; static unsafe void Main(string[] args) { Program pg = new Program(); fixed (int* p2 = &pg.value) { Console.WriteLine("SyncBlock Index: " + (*(p2 - 2)).ToString("x")); Console.WriteLine("MethodTable Address: " + (*(p2 - 1)).ToString("x")); Console.WriteLine("첫번째 필드 값: " + (*(p2 - 0)).ToString("x")); Console.WriteLine("[unknown field]: " + (*(p2 + 1)).ToString("x")); } } } // 출력결과 SyncBlock Index: 0 MethodTable Address: 1d3810 첫번째 필드 값: ff [unknown field]: 0
지금까지 살펴본 코드에 착안해서 ^^ 현실성은 다소 떨어지지만... 재미있는 실험을 하나 해볼까요? ^^
다음은, 무한 대기 상태로 빠지는 예제입니다.
class Program { public int value = 0xff; static void LockThread(object lockObject) { lock (lockObject) { Console.WriteLine("You can't see this message!"); } } static unsafe void Main(string[] args) { Program pg = new Program(); lock (pg) { Thread t1 = new Thread(LockThread); t1.Start(pg); t1.Join(); } } }
그런데, 다음과 같이 강제로 SyncBlock Index 값을 설정/해제하는 코드를 작성하고,
unsafe static void ForceSetLock(object lockObject, int oldValue) { Program pg = lockObject as Program; fixed (int* p2 = &pg.value) { *(p2 - 2) = oldValue; } } unsafe static int ForceReleaseLock(object lockObject) { Program pg = lockObject as Program; int lastValue = 0; fixed (int* p2 = &pg.value) { lastValue = *(p2 - 2); *(p2 - 2) = 0; } return lastValue; }
LockThread 에서 lock 을 얻는 앞 뒤로 다음과 같이 처리를 해주면,
static void LockThread(object lockObject) { int oldValue = ForceReleaseLock(lockObject); lock (lockObject) { Console.WriteLine("You can't see this message!"); } ForceSetLock(lockObject, oldValue); }
^^ 정상적으로 lock 을 얻는 것을 확인할 수 있습니다. 참고로, ForceSetLock 을 호출하지 않는 경우 - 즉, 나중에 SyncBlock index 값을 돌려놓지 않으면 t1.Join() 함수에서 다음과 같은 예외가 발생합니다.
System.Threading.SynchronizationLockException was unhandled Message=Object synchronization method was called from an unsynchronized block of code. Source=ConsoleApplication1 StackTrace: at ConsoleApplication1.Program.Main(String[] args) in D:\...\Program.cs:line 57 at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException:
암튼... 재미있는 탐구였지요? ^^
(첨부된 파일은 위의 코드를 포함한 예제 프로젝트입니다.)
참 재밌네요 ㅋㅋㅋ