MAXIMUM_WAIT_OBJECTS :: 2006/06/04 00:28


디버깅 작업을 할때마다 늘 느끼는 거지만 디버깅을 할 때 가장 중요한 것은 모든 것을 의심해야 한다는 점이다. 의심하고 또 의심하고, 만약 의심하지 않은 한 가지가 있다면 그놈이 버그의 원인이다. 몇일간 지겹도록 멀티쓰레딩 관련 코드를 작성하는데 버그를 잡을 수 없었다. 트레이스 메시지를 곳곳에 뿌려놓았지만 이유를 알 수 없었다.

코드는 굉장히 간단하다. N개의 작업을 쓰레드 풀을 만들어 쓰레드 개수만큼 분산 처리 하는 코드를 작성하는 것이었다. 이상하게 쓰레드 개수가 한 30개 일때는 잘 되는데 100개가 되면 오류가 나는 것이었다. 희한한 일이었다. 거기다 가끔 100개로 동작시켜도 어쩔때는 잘 될때도 있었다. Sleep을 몇군데 넣으니 잘 돌아가는 확률이 높아졌다. 하지만 여전히 가끔은 이상하게 동작하는 것이었다. 그러다 오늘에야 그 원인을 알게 되었다. 너무도 당연히 잘 될거라고 리턴값도 체크해 보지 않은 WaitForMultipleObjects가 오동작을 한 것이었다.

MSDN을 찾아보니 WaitForMultipleObjects는 MAXIMUM_WAIT_OBJECTS 개수를 넘는 것을 대기하지 못한다고 되어있었다. 덴장~ 상수를 찾아보니 64로 정의되어 있다. 그러니 당연히 100개의 이벤트를 대기하는데는 실패할 수 밖에 없었던 것이다. 곰곰 생각해 봐도 당췌 그놈이 어떻게 구현이 되어 있길래 그러한 제한을 주는지 알 수 없다. 핸들목록도 우리가 다 제공하는데 왜 64개로 제한한 것일까??? 희한하다~

하여튼 디버깅을 할 때에는 모든것을 다 의심해 보는 것이 좋다~ 의심하고 또 의심하고 또 의심해야 한다~

네이버에 북마크 다음에 북마크 마가린 바르기 HanRSS에 북마크하기 이올린에 북마크하기 News2.0에 투고하기 del.icio.us에 북마크하기 Digg에 번역해 투고하기 dzone에 번역해 투고하기 붐바
이올린에 북마크하기(0) 이올린에 추천하기(0)
스폰서
글타래

Trackback Address :: http://www.jiniya.net/tt/trackback/213
  • Gravatar Image.
    Z | 2006/06/04 01:12 | PERMALINK | EDIT/DEL | REPLY

    NTSTATUS
    NtWaitForMultipleObjects (
    IN ULONG Count,
    IN HANDLE Handles[],
    IN WAIT_TYPE WaitType,
    IN BOOLEAN Alertable,
    IN PLARGE_INTEGER Timeout OPTIONAL
    )
    {
    //
    // If the number of objects is zero or greater than the largest number
    // that can be waited on, then return and invalid parameter status.
    //
    try {
    if ((Count == 0) || (Count > MAXIMUM_WAIT_OBJECTS)) {

    Status = STATUS_INVALID_PARAMETER_1;
    leave;
    }
    // If the wait type is not wait any or wait all, then return an invalid
    // parameter status.
    //

    if ((WaitType != WaitAny) && (WaitType != WaitAll)) {

    Status = STATUS_INVALID_PARAMETER_3;
    leave;
    }

    • Gravatar Image.
      codewiz | 2006/06/04 03:12 | PERMALINK | EDIT/DEL

      ㅎㅎ~ 질럿님 빨리도 리플 다셨네용~
      결국은 내부 지역 변수 버퍼 크기 때문이군요.

Name
Password

Homepage
Secret