Programmer J

Windows Vista 부터 새로 생긴 API로 CompareStringEx 라는 것이 있습니다.

이 함수는 이름을 보면 알듯이 문자열을 비교하는 것인데 일반적인 문자열 비교함수와 조금 다른 점이 있습니다.

 

일반적인 문자열 비교에서는 문자열 "10"과 문자열 "3"을 비교하면 문자열 "3"이 더 큰 것으로 나옵니다.

그러나 보통 위 문자열을 비교한다면 숫자 비교처럼 결과가 나오기 바라는 경우가 많을 것 입니다.

이때 CompareStringEx를 사용하면 좋습니다.

 

바로 예제 들어갑니다.^^

 

  < 결과 >

 

결과를 보면 알 수 있듯이 CompareStringEx를 사용할 때 두 번째 인수로 비교 플래그 값을 설정할 때 SORT_DIGITSASNUMBERS 을 사용하면 문자열 비교를 숫자의 크기로 비교해 줍니다.^^

 

CompareStringEx

MSDN : http://msdn.microsoft.com/en-us/library/dd317761%28VS.85%29.aspx

Windows7은 사용자뿐만이 아닌 개발자에게도 편리한 기능을 가지고 있습니다.
그 중에 '대기 체인 분석' 이라는 것이 있습니다.
이것을 사용하면 프로그램을 종료 시켰는데는 프로세스는 죽지 않고 살아 있는 경우 어디서 문제가 되었는지 어느 정도 알아낼 수 있습니다.


이 프로그램은 제가 집에서 만든 서버 애플리케이션으로 X 버튼을 눌러서 종료시킵니다.


그런데 작업 관리자를 보면 프로세스가 아직 죽지 않았습니다(ProjectHF2.exe)

이 문제는 보통 워커 스레드를 사용하는 경우 특정 스레드가 죽지 않아서 발생하는 경우일것입니다.
그럼 어떤 스레드가 대기 상태에 있는지 알기 위해서 대기 체인 분석을 사용해보겠습니다.


리소스 버튼을 누르면 아래의 창이 나옵니다.


위 그림과 같이 프로세스를 선택 후 메뉴에서 '대기 체인 분석'을 선택합니다.


위와 같은 화면이 나오고 어떤 스레드가 어떤 이유로 대기하고 있는지 설명해줍니다.

이 기능은 Windows API 중 Wait Chain Traversal를 사용한 것입니다.
http://msdn.microsoft.com/ko-KR/library/ms681622(VS.85).aspx

어느 정도 제한은 있지만 이 API를 사용하면 데드락 상황도 판단할 수 있습니다.

시스템 에러가 발생해서 GetLastError()을 사용해서 에러 값을 보면 숫자이기 때문에 어떤 에러인지 알기 힘듭니다. 이때 Win32 API인 FormatMessage를 사용하면 에러 문자열로 변환해주므로 에러 내용을 알기 편합니다.


제 경우는 네트웍에서 에러가 발생하면 아래와 같이해서 로그로 남기도록 합니다.




이 API를 사용하기 위한 조건
OS : Windows 2000 이상
헤더파일 : winbase.h(windows.h에 포함되어 있음)
라이브러리 : kernel32.lib
DLL : kernel32.dll


자세한 내용은 아래를 참고해 주세요

MSDN : http://msdn.microsoft.com/en-us/library/ms679351%28VS.85%29.aspx

CryptGenRandom는 랜덤 값을 생성하는 함수로 C 라이브러리의 rand와 비슷합니다.

틀린 점은 rand는 랜덤 값이 예측 가능하고 CryptGenRandom는 암호화 기능을 사용하여 예측 할 수 없는 랜덤 값을 생성해 줍니다.
(rand의 경우 srand을 사용한 후 사용해야 이전과 중복되지 않은 패턴으로 랜덤 값을 생성합니다)

 

CryptGenRandom의 또 하나의 장점은 시드 값의 자료형 크기를 넘지 않는 랜덤 값을 생성합니다.
즉 시드 값의 자료형이 unsigned char라면 CryptGenRandom을 사용한 랜덤 값은 0 ~ 255 사이의 값만 나옵니다.

CryptGenRandom는 기존의 srand+rand의 조합에 비해서 장점이 있지만 단점도 있습니다. 단점은 성능입니다. CryptGenRandom가 암호화 기능을 사용하므로 rand에 비해서 느립니다. Win32 API에서는 어느 정도 차이가 나는지 잘 모르겠지만 똑 같은 기능이 있는 닷넷에서는 rnad와 CryptGenRandom의 성능 차이는 대략 100배 정도라고 합니다.

 

 

 

참고

Step By Step: Visual C++에서 난수 생성 방법
http://support.microsoft.com/kb/983137/ko

 

[MSDN] CryptoRandom 이야기
http://msdn.microsoft.com/ko-kr/magazine/cc163367.aspx

 

시간 계산 어떻게 하시나요?

여러 가지 방법이 있겠지만 SYSTEMTIME을 사용하여 계산하는 경우라면 COleDateTime과 COleDateTimeSpan을 사용하여 계산하면 쉽게 할 수 있습니다.

COleDateTime과 COleDateTimeSpan은 ATL에 있는 라이브러리입니다.

 

 

COleDateTime과 COleDateTimeSpan을 사용하기 위한 조건

필요한 파일 : ATLComTime.h

 

 

예제

아래 예제는 지정된 시간에서 ‘분’을 더한 시간을 계산합니다.

 

COleDateTime은 생성자에서 SYSTEMTIME을 인자로 사용할 수 있습니다. 그러나 인자로 사용할 SYSTEMTIME의 값이 올바른 값인 경우만 사용할 수 있습니다. 예를 들어 아래와 같은 것을 인자로 넘기면 디버그 모드에서는 경고가 발생합니다.

 

 

프로그램에서 현재 실행 중이 컴퓨터의 CPU에 대한 정보를 알아야 할 때가 있습니다.

예를들면

1. CPU가 32비트인지 64비트인지

2. 코어가 몇 개 있는지

등등...

이런 정보를 알고 싶을 때는 Windows 2000 때까지는 GetSystemInfo를 사용했습니다.

그러나 GetSystemInfo는 64비트 Windows에서 이 API를 사용하는 프로그램은 32비트 프로그램이라면 잘못된 정보를 가져옵니다. 그래서 32비트나 64비트 환경에 상관 없이 정확한 정보를 얻기 위해서는 GetNativeSystemInfo를 사용해야 합니다.

GetNativeSystemInfo는 64비트 환경에서는 내부적으로 GetSystemInfo를 호출합니다.

 

 

 

 

GetNativeSystemInfo를 사용하기 위한 조건

 

OS : Windows XP 이상

필요한 파일 : windows.h

필요한 라이브러리 : kernel32.lib

필요한 dll : kernel32.dll

 

이 API를 사용할 때 헤더파일에 _WIN32_WINNT 선언이 0x0501 이상이어야 합니다.

 

 

예제

결과

QueryPerformanceCounter가 나오기 전에는

 

x86 P5 명령 셋 도입 이후 높은 정밀도의 시간을 얻기 위해서 RDTSC(Read Time Stamp Counter)를 사용하였습니다. 그러나 RDTSC는 아래와 같은 문제가 있었습니다.

 

1. 연속성 없는 값. 멀티 코어, 멀티 프로세스에서는 코어간의 사이클 카운터가 동기화 되지 않습니다.

2. 전용 하드웨어의 가능성. RDTSC가 나온 이후 시간이 지나면서 마더보드에서 높은 정밀도의 시간 정보를 제공하는 디바이스를 제공하고 있습니다.

3. CPU 주파수의 변동성. 전원관리기술에 의해서 CPU 주파수가 변동됩니다.

 

위와 같은 문제를 안고 있는 RDTSC를 대체하기 위해 Win API에서는 QueryPerformanceCounter를 제공합니다.

 

 

 

그런데 QueryPerformanceCounter는 멀티 코어, 멀티 CPU에서 문제가 없을까요?

 

아니요 있습니다. RDTSC의 1번 문제처럼 이것도 ‘연속성 없는 값’ 문제를 해결하지 못하고 있습니다. QueryPerformanceCounter를 문제 없이 사용하기 위해서는 이것을 하나의 스레드에서 사용하고 이 스레드를 하나의 프로세서에 고정시켜야 합니다.

 

원래 이 API 자체가 이런 멀티 코어, 멀티 CPU를 생각하지 않고 나온 것이 아닙니다. 오히려 이런 문제를 해결하는 것이 목적 중의 하나입니다. 그런데 왜 특정 프로세서에 고정시켜서 사용해야 할까요? 이유는 두 가지가 있습니다.

 

1. 하드웨어 버그

이것은 마이크로 소프트의 문제가 아니고 하드웨어 업체의 문제입니다. BIOS나 드라이버에 버그가 있으면 스레드가 프로세서 간 이동할 때 이들 루틴에서 서로 다른 값을 넘기는 경우가 있어서 이런 하드웨어 버그를 피하기 위해서 특정 프로세서에 고정시키는 것이(SetThreadAffinityMask 사용) 좋습니다.  

 

2. 병목

각 워커 스레드에서 시간 계산을 하면 각 스레드로부터 동기화 하기 위해 락을 걸어야 하므로 이것에 의한 병목이 발생합니다. 이것을 막기 위해서 하나의 스레드에서 시간 계산을 하도록 하여 락을 사용하지 않도록 합니다.

 

 

 

그럼 QueryPerformanceCounter를 하나의 스레드에서만 사용하고 이 스레드를 특정 프로세서에 고정시키는 것으로 문제는 없을까요?

 

아닙니다. 문제(?)는 여전히 있습니다. 이 문제는 근래에 생긴 문제로 원인 제공은 인텔입니다. 바로 인텔의 네할렘 계열 CPU가 문제가 됩니다. 네할렘 계열 CPU로는 i3, i5, i7이 있는데 이들 CPU는 ‘터보 부스터’ 기능이 있습니다. 이 기능은 각 코어의 주파수는 2.6인데 특정 코어가 부하가 걸리고 나머지 코어가 여유가 있으면 부하가 걸린 코어의 주파수를 올려줍니다(즉 2.6이 2.8이 되어버립니다).

 

‘주파수를 올려준다’ 이 말에서 문제를 아시겠죠? OS에서는 시스템이 시작할 때 CPU의 주파수를 설정한 후 이후 다시 시스템을 재 시작 하기 전까지는 변경하지 않습니다. 그리고 QueryPerformanceCounter도 OS가 설정한 CPU 주파수를 사용합니다. 그런데 ‘터보 부스터’ 기능에 의해서 실제 주파수는 변경되어 버립니다. 그래서 ‘터보 부스터’가 작동하면 QueryPerformanceCounter의 값은 작동하기 전과 다른 값이 나와버립니다.

 

그래서 성능 측정에서 QueryPerformanceCounter을 사용할 때는 ‘터보 부스터’ 기능을 off로 해 놓아야 합니다. 그리고 게임과 같은 애플리케이션에서 사용할 때는 ‘터보 부스터’에 의해서 오차가 생길 수 있음을 유의해야 합니다.

 

 

 

‘터보 부스터’와 QueryPerformanceCounter 문제 해결 방법은?

 

이건 저도 모릅니다.^^;

다만 Windows 7에서는 이런 문제가 없다고 합니다. 이유는 Windows 7는 이전 OS와 다르게 QueryPerformanceCounter에 다른 레퍼런스 클럭을 사용하고 있기 때문에 CPU 주파수가 변동 되어도 영향을 받지 않는다고 합니다. 참고로 이런 이유로 Windows 7의 QueryPerformanceCounter의 부하가 XP 보다 조금 높다고 합니다.

 

 

 

 

참고

http://msdn.microsoft.com/ja-jp/library/bb173458%28VS.85%29.aspx

http://d.hatena.ne.jp/shiku_otomiya/20100218/p1

http://d.hatena.ne.jp/shiku_otomiya/20100504/p1