Lock , lock , lock … – rein ' s world 
 Lock , lock , lock … 
 멀티 스레드 프로그램 을 작성 하 는 경우 – 웹 서버 처럼 스레드 상호 간 의 연관 성 이 적 은 경우 를 빼 면 – 스레드 간 에 공유 자원 에 접근 하 는 부분 은 언제나 문제 가 된다 . 
 제대로 작성 하 는 방법 은 크 게 3 2 가지 다 . 
 대충 짜 고 행운 을 기대 한다 ( Luck - oriented programming ) – 주변 의 사례 들 에서 이런 경우 가 상당히 많 다 ( 당연히 안 돌 고 디버깅 한다 낄낄 ) 
 Lock 을 써서 해당 영역 을 하나 의 스레드 만 접근 하 게 한다 – 적절 한 난이도 
 Lock - free 한 구성 을 만들 어 낸다 – 잘 정의 된 몇 가지 경우 를 제외 하 고 는 적용 하 기 가 매우 힘들 다 ( … ) 
 우선 그나마 적절 한 난이도 를 갖 는 lock 을 사용 한 프로그래밍 에 관해서 이번 포스팅 에서 몇 가지 를 설명 하 려고 한다 . 
 Lock 이 사용 되 는 형태 는 매우 단순 하 다 . 동시 에 2 개 의 스레드 에서 실행 해선 안 되 는 코드 – 예 를 들 어 웹 서버 에서 각 IP 별 접근 횟수 를 기록 하 고 있 고 , 이게 하나 의 함수 안 에서 이루어진다고 하 자 – 가 있 을 때 , 해당 코드 의 시작 / 끝 을 Lock 으로 감싸 는 형태 를 띈다 . 이 부분 을 RAII 형태 로 사용 하 거나 , 좀 더 예쁜 구문 으로 사용 하 는 방법 은 리카 넷 : synchronized block in C ++ 을 참 고 하 자 . 
 예 를 든 걸 코드 로 간단히 표현 해 보 면 , 
 void increment _ ip _ counter ( const int 32 _ t ipv 4 _ address ) 
 정도 가 될 것 이 다 . ( counter 는 std : : map < int 32 _ t , unsigned int 64 _ t > 정도 로 생각 해 주 자 ) 
 동시 에 2 개 이상 의 스레드 가 카운터 를 바꾸 는 것 만 막 으면 문제 가 안 되 기 때문 에 이런 형태 로 보호 하 면 된다 . 상당 수의 lock 을 사용 하 는 코드 는 이런 형태 로 되 어 있 다 . 
 사실 문제 가 되 는 것 은 이런 1 개 의 lock 을 사용 한 경우 가 아니 다 . ( 물론 priority inversion , lock convoy 같 은 문제 가 존재 하 긴 한다 ) 
 복수 의 lock 을 획득 하 는 경우 가 주로 문제 가 된다 . 구체 적 으로 말 하 면 dead - lock 이 발생 할 수 있 다 . 
 Dead lock 이 란 것 은 2 개 이상 의 스레드 가 서로 가 다른 스레드 가 이미 가지 고 있 는 lock 을 원해서 무한히 대기 하 게 되 는 상황 을 말 한다 . 예 를 들 어 스레드 T 1 이 lock L 1 , L 2 를 가지 고 있 고 , 스레드 T 2 가 lock L 3 를 가지 고 있 는데 , T 1 이 L 3 를 , T 2 가 L 2 를 추가 로 가지 기 원 하 는 상황 이 되 면 T 1 은 T 2 가 lock 을 내려놓 기 를 , T 2 는 그 반대 를 기다리 게 된다 . 
 이걸 어떻게 피해 갈까 ? 많 은 현대 OS 나 MT 프로그래밍 에서 많이 사용 되 는 방법 은 굉장히 단순 하 다 . 모든 lock 에 번호 를 붙이 고 ( 실제로 lock 을 획득 하 는 경로 에 대해 strict ordering 이 나오 기 만 하 면 된다 ) , 여러 개 의 lock 을 잡 을 때 에 는 항상 이 순서 를 유지 하 는 것 이 다 . 간단 한 방법 이 지만 이 방법 하나 로 모든 dead lock 을 회피 하 게 된다 . 
 직전 에 언급 한 예제 의 경우 , T 2 가 L 3 를 이미 잡 고 있 기 때문 에 , 그 보다 번호 가 작 은 L 1 이나 L 2 를 요청 하 는 경우 는 lock ordering 을 사용 하 는 경우 발생 할 수 가 없 고 , 이 에 따라 여러 스레드 가 서로 가 서로 를 요구 하 는 ( lock 을 요구 하 는 ) cycle 이 생기 질 않 는다 . 
 Multi thread 의 세계 에서 일 하 는 것 은 힘들 다 . 그렇지만 몇 가지 원칙 – 여기 에서 는 lock 을 잡 는 순서 만 언급 했 지만 – 을 지키 면 그나마 다룰 만 한 무언가 가 된다 . 그런 의미 에서 lock 을 어떻게 잡 아야 dead lock 을 피할 수 있 는지 꼭 기억 하 자 [ … ] 
 ps . 이 글 역시 지금 참여 중 인 프로젝트 코드 에 저런 게 있 었 기 때문 에 나온 거 라곤 말 못 한다 . 
 Posted on 2007 - 08 - 14 2010 - 02 - 19 Author reinCategories ComputerTags C ++, Programming , 멀티스레딩 
 10 thoughts on “ Lock , lock , lock … ” 
 2007 - 08 - 14 at 12 : 30 pm 
 나 도 락킹 의 프로그래밍 모델 을 깔끔 하 게 세워 보 려고 이리저리 생각 중 인데 쉽 지 가 않 다 . 
 요즘 Beautiful code 책 의 한 챕터 로 추정 되 는 Beautiful concurrency 를 읽 는 중 . 
 ( http : / / research . microsoft . com / ~ simonpj / papers / stm / beautiful . pdf ) 
 2007 - 08 - 14 at 12 : 35 pm 
 그 뭐 랄까 요즘 MT 쪽 의 새로운 빌딩 블 럭 을 제안 하 는 게 많 은 것 같 은데 , 아무래도 지금 스레드 쪽 뭔가 를 만들 어 내 기 위한 기초 데이터 ? 루틴 ? 같 은 게 부족 한 거 같 음 . 
 모 블로그 에 트랙백 날리 는 중 에 모 블로그 주인장 답글 이 달렸 다 [ … ] 
 2007 - 08 - 14 at 12 : 50 pm 
 다익스트라 영감 님 같 은 분 이 나와서 Lock Considered Harmful 같 은 거 라도 써 주 시 게 될까 낄낄 
 검색 해 보 니까 Caps - Lock Considered Harmful 은 많이 나오 네 … 
 Threads Considered Harmful 은 있 군 . 
 2007 - 08 - 14 at 1 : 03 pm 
 근데 뭐 랄까 considered - harmful 이 라도 , 더 이상 CPU 속도 가 빨라 지 기 힘드 니 스레드 가 사실 상 존재 하 는 성능 향상 의 마지막 대안 이 라는 생각 들 도 요즘 꽤 많 지 
 좀 된 거 지만 http : / / gotw . ca / publications / concurrency - ddj . htm : The Free Lunch Is Over : A Fundamental Turn Toward Concurrency in Software by Hurb Sutter 이런 글 도 
 2007 - 08 - 14 at 6 : 08 pm 
 병렬 인 트린 식 들 을 써서 , 처리 흐름 은 하난데 개별 데이터 처리 를 병렬 화 . . 하 는 식 의 완전 다른 접근 도 있 는 듯 . 
 게임 에서 는 쓰 기 어려울 듯 하 지만 -_- 
 2007 - 08 - 14 at 6 : 31 pm 
 게임 은 서로 얽혀 있 는 건 뭣 같이 많 아서 병렬 화 하 기 가 참 [ … . ] 
 2007 - 08 - 14 at 10 : 54 pm 
 뭔가 대인배 들 의 리플 놀이 인 듯 
 2007 - 08 - 15 at 2 : 34 am 
 Pingback : rein ’ s world » Lock , lock , lock … # 2 
 Pingback : 멀티스레딩 과 STL | rein ’ s world 
 Previous Previous post : 컴퓨터 업그레이드 
 Next Next post : Windows 키 맵 핑 바꾸 기