첫번째 경우는 이해가 된다. 최적화를 떠나서 스케줄링에 따라서는 무한 루프에 빠질 가능성이 다분한 코드이다. 그러나, 내 지식으로 --; 두번째 예제는 솔직히 이해가 되지 않는다. ( +_+ 예제를 돌려봐야 겠당 ㅋㅋ) 여하튼 컴파일러의 최적화 알고리즘에 의해 이런 사황들이 발생할 수 있다는 것이 참 신기하다.
그러나, 기실은 나도 경험했던 것이지만, 애써 망각하려 했을지도 모르겠다. 나도 전에 상태 변수 체크를 통해 스레드의 Termination 여부 및 루프 중지, 또는 동기화 결정을 하는 클래스를 설계하고 디버깅시 Debug 모드에서는 예상되로 동작하는데 Release Mode에서는 이상하게 꼬이거나 Termination이 제대로 되지 않아 고생하다가 원인을 알고자 하는 것보다는 아마도 시간에 쪼겨 상태 변수를 포기하고 동기화를 위한 도구로 Window의 커널 객체인 Event로 교체후 문제 없이 돌렸던 경험이 있다.
이 글을 보니 그때의 기억이 스물 스물 머리에서 기어나온다. --;
지금도 Window 삽질시 Thread 간의 동기화를 위해서는 그동안 문제가 없었던 Event 객체를 사용하고 있다. (리눅스는 Thread간 동기화에 세마포어나 시그널을 가끔 썼고, 대부분은 Critical Section으로 충돌이 발생할 확률이 있는 변수를 보호해 주고 그냥 자기혼자 알아서 다하고 죽는 경우가 대부분이 었던 것으로 기억된다)
이 글을 통해 컴파일러 최적화 알고리즘에 따라 스레드에 의해 보호받지 못하는 Object로 동기화를 할경우 생길 수 있는 위험에 대해 알게되어 기쁘다.
스레드 사용시 학문적인 Dead lock, Race Condition 같은 문제 외에도 컴파일러 최적화와 같은 외부요인에 의해 생길 수 있는 문제가 있다는 것을 오늘 인지한것 같다.
기억이 꼬리에 꼬리를 문다.
지금 생각하니 조금은 어처구니 없을지도 모르지만 내가 경험한 Thread Programming시 가장 골치 아팠던 문제는 Race Condition(이건 오히려 얘교였다 ^^) 보다도 1byte stack overflow(메모리 잘못 조작)에 의해 스레드 들이 이쪽 저쪽에서 아무 규칙 없이 뻗어버리는 상황이었다. 처음 이런 현상에 직면하고 문제의 원인을 알게 되었을 때는 정말 맥이 쭉 빠지는 것 같았던 걸로 기억한다.
