지난 주에 나간 퀴즈에 여러 분들의 열화와 같은 성원에 힘입어 서둘러 글을 쓰게 되었다. (열화와 같은 성원은 무슨... -_-; 항상 오는 독자들만 와서 글 남겼더만... -_-) 쓸데 없는 소리는 집어 치우고 곧장 본론으로 들어가자.

Answer: Synchronization Tip

지난 글의 문제는 다음 리스트1 에서 버그를 찾는 것이었다.

리스트1. 키-값 검색을 하는 룩업(lookup) 테이블 클래스

사실 다중 쓰레드의 동기화에 관련된 문제는 그 원인을 파악하기 매우 힘들다. 필자가 다중 쓰레드의 문제가 발생할 때 주로 사용하는 방법은 로깅(logging)을 사용하여 코드를 추적하면서 강제적인 지연을 통해 여러 쓰레드가 동시에 동일 코드 블록을 수행하도록 하여 고의적으로 문제 현상을 만드는 것이다. 디버거(debugger)를 이용한 디버깅은 이와 같은 동기화 문제를 해결하는데 도움을 주지 못하는 경우가 많았다. 당연히 그럴 것이 대부분의 코드가 단일 쓰레드 상에서는 아주 잘 작동하기 때문이다.

리스트1 에서 동기화 문제의 가능성은 같은 key 값을 가지고 PublishValue 라는 메쏘드가 2개 이상의 쓰레드에 의해 진입될 수 있다는 점이다. 아니 C8 그게 말이 되는가? PublishValue 메쏘드는 private 인데다가 PublishValue 메쏘드를 호출하는 코드(13 라인)를 lock 키워드로 감싸놓아 동기화를 해 놓지 않았는가?

Reasoning

필자가 언급한 가능성을 확인하기 위해 PublishValue 메쏘드를 약간 수정해 보자. 먼저 PublishValue가 호출되었음을 알리기 위해 Console.WriteLine을 이용하여 로그를 남기고, PublishValue를 호출한 쓰레드가 잠시 sleep 되도록 Thread.Sleep을 호출한다. Thread.Sleep이 호출되면 호출한 쓰레드는 블로킹(blocking)되며 이는 데이터베이스 액세스나 웹 서비스 호출에 대개 동반되는 블로킹과 동등한 현상이라 간주하면 되겠다.

리스트2. 변경된 PublishValue 메쏘드

PublishValue 코드를 리스트2와 같이 수정하고 LookupTable 테이블을 사용하는 호출자 코드를 리스트3과 같이 작성해 보자.

리스트3. LookupTable 클래스를 사용하는 호출자 코드

리스트3은 3개의 쓰레드를 만들고 이 쓰레드가 LookupTable.Lookup 메쏘드에 대해 2라는 키 값을 통해 호출하는 것이다. 세 쓰레드가 모두 키 값으로 2를 사용하고 있으므로, 수행 결과로서 예상할 수 있는 것은 PublishValue 메쏘드가 1회 호출되는 것으로 Console.WriteLine에 의해 출력되는 메시지가 1회 일 것이다. 리스트4는 수행 결과를 보여주고 있다.

리스트4. 버그를 포함한 코드의 수행 결과

What's the Problem ?

이런... 이게 무슨 조화일까? PublishValue 메쏘드가 3회나 호출된 것으로 결과가 나왔다. 분명 리스트1은 하나의 키 값에 대해 한 번의 PublishValue 호출이 일어나도록 의도 되었음은 의심할 바가 없다. 분명 무언가 잘못되어 있는 것이다. (당연히 잘못됐겠지... 그러니깐 문제랍시고 내 놓은 거 아닌가?)

원인은 이렇다. 세 개의 쓰레드 t1, t2, t3 가 Lookup 메쏘드를 호출하게 되면, 세 쓰레드는 모두 키 값 2에 대해 null 을 발견하게 될 것이다(리스트1의 라인 10). 그리고 세 쓰레드 중 한 쓰레드는 lock 키워드에 의해 잠금을 획득하고 lock 코드 블럭 안으로 진입할 것이고(이 쓰레드를 t1 이라 가정하자), 나머지 두 쓰레드는 lock 에 의해 블로킹 되어 리스트1의 라인 12에서 수행이 멈춘 채 잠들게(sleep) 될 것이다. t1 쓰레드는 PublishValue를 호출하여 키에 대한 값을 조회하고 이 값을 캐시 하기 위해 다시 해시 테이블에 삽입한다(리스트1의 라인 13-14).

여기까지는 매우 좋다. 그런데... t1 쓰레드가 lock 블럭을 빠져나가게 되면(잠금이 풀리게 됨) t2, t3 쓰레드 중 한 쓰레드(t2 라고 해 보자)가 다시 lock 블럭 안으로 진입하여 PublishValue 메쏘드를 호출하는 현상(?)이 발생한다. 그리고 최종적으로 마지막 쓰레드 하나(t3가 될 것이다) 역시 t2 쓰레드가 lock 블럭을 빠져 나간 후 다시 lock 블럭으로 진입하여 아무렇지도 않게 PublishValue를 호출하게 될 것이다.

리스트1의 경우 해시 테이블을 사용하고 인덱서(indexer) 속성을 사용했기 때문에 동일한 키에 대해 PublishValue가 여러 번 호출되더라도 성능 상의 저하 만 올 뿐 예외가 발생하지 않았다. 만약 인덱서가 아닌 Add 메쏘드를 호출했었다면 얄짤없이 ArgumentException이 발생했을 것이다.

비록 여러 쓰레드가 lock 문장에 의해 한꺼번에 블로킹 될 가능성은 높은 편은 아니다. 이렇게 동기화 문제의 대부분이 평소에는 아무런 문제가 없어 보인다는 것이다. 개발 기간에는 대개의 경우 부하가 크게 걸리지 않기 때문에 이러한 동기화 문제를 인지하지 못하곤 한다. 그러다가 실제 개발이 완료되고 운영되는 시점에서, 그것도 부하가 몰리는 상황이라면 충분히 이런 현상을 겪을 수 있게 되는 것이다. 이것이 다중 쓰레드의 동기화 문제가 우리를 아프게 만드는 점이기도 하다.

Solution

리스트1과 같이 테이블 자체를 퍼블리싱 하거나(한방에 해시 테이블을 채우는 걸 생각 하문 되긋다) 테이블의 각 아이템을 퍼블리싱 할 때는 항상 여러 쓰레드에 의해 테이블이 업데이트 되는 상황을 고려해야 한다. 그리고 이 때 간단히 lock 혹은 Monitor.Enter ~ Monitoer.Exit 메쏘드 호출을 사용하곤 한다. 이 때 항상 주의해야 할 사항은 앞서 언급한 대로 동시에 여러 쓰레드가 lock 혹은 Monitor.Enter에 걸려서 잠 퍼 자는 시나리오에 주의를 기해야 한다. 비록 lock 에 의해 보호되는 코드는 오직 하나의 쓰레드 만이 수행될 것임은 분명하다. 하지만 동시에 여러 쓰레드가 lock 에 걸리는 상황이라면 이들 쓰레드 중 하나의 쓰레드 만이 lock이 보호하는 코드 블록을 수행하고 나머지 쓰레드는 lock 에서 블로킹 되며 언젠가는 이들 블로킹 된 쓰레드는 블로킹이 풀려 lock 이 보호하는 코드를 수행하게 된다.

따라서, lock이 보호하는 코드 일지라도 특정 작업을 수행해야 할지 말아야 할지 다시 한번 검사하는 과정이 필요하다. 말로만 하면 졸라 햇갈리고 이해도 안 가므로 코드를 살펴 보자.

리스트5. 버그를 수정한 LookupTable 클래스

리스트5는 버그를 수정한 LookupTable 클래스를 보여주고 있다. 리스트1에 비해 달라진 것이라곤 라인 12 부터 라인 15까지 이다. lock 이후 다시 한번 해시 테이블로부터 해당 키 값이 있는지 검사하고 여전히 키에 대한 값이 존재하지 않을 경우에만 PublishValue를 호출하게 된다. 키 값을 두 번씩이나 검사하는 좀 이상하게 보이는 코드이지만 이러한 패턴의 코드는 상당히 자주 등장한다. lock 과 같이 상호 배제(mutual exclusion)를 제공하는 동기화 메커니즘에서 추가적으로 특정 보호되는 코드를 수행해도 되는지 검사를 추가적으로 해야만 경우가 많이 발생하곤 한다. (항상 그렇지는 않다)

독자들 중에 리스트5 보다는 다음과 같은 코드를 이용하여 Lookup 메쏘드 전체를 lock로 보호하면 어떨까 생각하는 독자가 있을지 모르겠다.

위 코드는 동기화 문제를 해결하긴 하지만 동시성(concurrency)에 있어서는 빵점 짜리 코드 이다. 테이블에서 키 값을 읽을 때에도 잠금이 발생하기 때문에 테이블에 접근할 수 있는 쓰레드는 오직 하나가 되어 버린다. ASP.NET 웹 어플리케이션과 같이 다중 쓰레드 환경이라면 LookupTable 클래스를 동시에 액세스 하는 수십, 수 백 개의 쓰레드는 쭈욱 일렬로 늘어서 손가락 빨며 자기 차례가 오길 기다려야 할 것이다.

닷넷 깨나 만져 봤고, MSDN 좀 뒤져본 독자라면 Hashtable.Syncronized 메쏘드에 대해 들어봤을 것이다. 요 메쏘드를 호출하면 동기화된 해시 테이블 객체가 반환된다. '동기화'가 된다고 그랬으니 이걸 이용하여 다음과 같이 코딩 하면 되지 않을까?

위 코드 역시 동일한 키 값을 사용하는 2개 이상의 쓰레드가 PublishValue 메쏘드를 여러 번 호출하는 문제를 막을 수는 없다. Hashtable.Synchronized 메쏘드가 반환하는 해시 테이블은 동기화를 제공해 주기는 한다. 이 동기화는 해시 테이블에 동시에 2개 이상의 쓰레드가 접근하지 못하도록 막아 줄 뿐이다. 이해를 돕기 위해 다음 두 코드 조각은 정확히 동일한 코드가 되겠다. 즉, Hashtable.Synchronized 메쏘드가 반환해 주는 동기화 버전의 해시 테이블은 해시 테이블에 대한 액세스(인덱서, Add 등)를 lock으로 감싸주는 역할만을 담당한다.

왜 Hashtable.Synchorized 를 사용하더라도 문제해결이 되지 않는 이유는 독자들이 자~알 생각해 보기 바란다.

Epilog

뭐 별로 쓰잘 것도 없는 내용을 가지고 주저리 주저리 떠든 느낌이 귀 언저리 살을 거쳐 후두부 그리고 대퇴부를 팍 걷어 찬다. 쯔읍... 졸라 복잡하고 어렵게 느껴진다면... 걍 조용히 까먹어도 될만한 토픽이지만... 하나 이 글에서 건져 갈만한 내용은 Hashtable.Synchronized 메쏘드가 반환하는 해시 테이블이 수행하는 작업 정도라고 할까? 그런 거 몰라도 먹고 사는데 지장 없다고 말해도 필자는 할말이 읍다... -_-;

자신이 정답을 말했다고 생각하는 독자는 언제고 필자를 찾아오길 바란다. 필자가 음주가무에 상당히 약한 관계로... 쓰디 쓴 커피 한 사발 정도는 대접할 수 있으니 말이다. 설마 찾아 오는 사람 있겠어 ? 흐흐흐...