엘키의 주절 주절

Thread design에 대한 이해는, 기본적으로 잠금 정책에 over head를 이해하고 있느냐에서 출발한다고 생각합니다. 잠금 기반 프로그래밍은, 자주 사용하는 코드가 잠기게 될수록 성능이 수직 하향합니다.대기 하느라, 제대로 된 퍼포먼스를 낼 수 없다는 얘기죠. 그렇게 하지 않기 위해, 객체 간에 잠금에 신경쓰지 않게끔, 객체 간 접점을 줄여주어야 합니다. 좋은 Thread design의 목표는 어떻게 잡아야 할까요? 접점 최소화손쉬운 비동기 처리의도한 대로 순차 처리 (순서가 중요한 동작의 순서 보장) 디테일하게 나열하자면 얼마든지 많겠지만, 저는 위 세가지 목표가 보장된 기반 코드는, 컨텐츠 구현 시에 필요한 요구 사항을 다수 충족 시킬 수 있습니다. 이런 문제가 현세대 멀티스레드 프로그래밍의..

제가 프로그래밍을 처음 배울 때의 CLI 프로그래밍과 WIN32 프로그래밍으로 넘어왔을 때 큰 괴리를 느꼈습니다.그 이유는 바로 EVENT-DRIVEN(message based)프로그래밍 때문이었죠.현재는 reactor라는 패턴이란 이름으로 더 알려진 이 메시지 기반 프로그래밍은, DOS 시절의 동기 프로그래밍에 익숙한 많은 프로그래머를 괴롭게 했습니다. message라는걸 왜 굳이 만들어 처리하는가….에 대해 저는 그 당시 이해하기 어려웠습니다.당시만해도, 윈도우 메시지를 굳이 처리하지 않고도 여러 작업이 가능했기 때문이죠. 예를 들어 GetAsyncKeyState (http://msdn.microsoft.com/ko-kr/library/windows/desktop/ms646293(v=vs.85).as..

클럭도 물론 중요하지만, 코어가 몇갠지 부터 보는 일이 자연스러워진지도 몇년. 다들 병렬 프로그래밍 잘 하고 계시나요? 서버 프로그래밍을 시작한 2006년부터 지금까지... 멀티 스레드를 다뤄오며, 느낀 것에 대해 이야기해보고자 한다. lock 말그대로 잠금. 이 데이터 unlock 될때 까지 쓰지말라는 거다. - non-blocking non-blocking이 뭐냐고? 대기하는 상황(blocking) 없이 코드가 수행되는 것을 말한다. - lock is blocking. lock이라는 것 자체가 blocking을 위한 녀석이다. 멀티스레드에 적합한 녀석 일리 없다. - lock-free container나 데이터에 접근할 때에 lock 객체에 대한 고민없이 사용해도 되는 자료구조나 스레드 모델을 loc..

1.Critical Section - 유저 레벨의 동기화 방법 중, 유일하게 커널 객체를 사용하지 않음. - 내부 구조가 단순하여 동기화 처리에 대한 속도가 빠르다. - 동일한 프로세스 내에서만 사용. - 커널 객체를 사용하지 않기 때문에 핸들을 사용하지 않고, CRITICAL_SECTION 이라는 타입을 정의하여 사용. ?12345678910111213141516// 크리티컬 섹션을 초기화한다. // 파라메터는 여러 개의 쓰레드에 참조되어야 하므로 전역으로 선언하도록 한다.void InitializeCriticalSection(LPCRITICAL_SECTION lpCriticalSection); // 생성된 크리티컬 섹션을 삭제한다. void DeleteCriticalSection(LPCRITICAL_..

서버 프로그래머가 되기 이전엔 멀티 스레드 따위 관심도 없었다.물론 그 시기까지가 클럭 향상 -> 멀티 코어로 변화가 이루어지기 전이기도 했지만... 여하튼 나는 그런 것 보단 다른 것들에 관심이 훨씬 많았다. 서버 프로그래밍을 시작하면서 멀티 스레드를 다루기 시작했고 만 7년이 된 지금까지 여러 프로젝트를 경험해왔고, 여러 사고를 쳐왔다. 그냥 정줄 놓은 누가 봐도 코드를 잘못 짜서 생긴 사고 (...)도 많았지만, 그보다 더 큰 사고는 주로 함정에서 발생했는데, 그 중 최고봉은 역시나 멀티 스레드 버그였다고 할 수 있다. 아니 아주 정확히는 멀티스레드에 맞게 코딩하지 못한 내 버그다. 내가 지금껏 프로그래밍을 공부해오며 생각해온 방식은 구조적 프로그래밍에 대한 이해를 전제로 해왔다.그러던 중 멀티스레..

캐싱의 기본은 지역성에 근거하는데요, 이는 프로그래밍단의 최적화에서도 유명한 80-20법칙과도 일맥상통하는 이야기죠. 지역성(locality)은 아래 추정에 근거합니다. 1. 지금 읽힌 데이터는 이후에도 자주 사용될 가능성이 높다. 2. 지금 읽힌 데이터와 인접한 데이터는 이어서 사용될 가능성이 높다. 이는 코드 실행시 스택 처리를 통해 얻게 되는 장점과 유사합니다. 단일 코어가 아닌 멀티 코어 CPU는 데이터를 읽어올때, 캐시 라인 (cache line)이란 단위로 읽어옵니다. 캐시 라인이라 함은 지역성에 근거해 인접한 데이터를 미리 읽어옴으로써 속도향상을 노리는 것이지요. 하지만 이는 장점이자 독이 되기도 합니다. 멀티코어에서는 A스레드와 B스레드에서 인접 메모리를 접근할때, 캐시에 있던 내용을 메모..

좋은 프로그램이란, 유휴 시간없이 하고 싶은 일을 최대한 많이 하는 프로그램을 의미합니다. 여기서 중요한 것은, 하고자 하는 일을 많이 해야 된다는 점이죠. 싱글 스레드 클라이언트 프로그램의 경우는 대게 아래와 같습니다. 1. 입력 받는 작업2. 연산 작업3. 화면 그리기 4. 1번으로 돌아감 시간을 재고, 특정 작업 시간이 오래 걸려 재 속도를 내지 못한다면, 연산량을 감소 시킬 수 있는 처리를 하거나 (초당 프레임 조정 등), 만약 연산량을 줄일 수 없는 경우라면 게임 속도가 느려지게 됩니다. 연산량을 감소시켜서라도 제속도를 낼 수 있는 임계치를 최소 사양이라고 부릅니다. 멀티 스레드 서버 프로그램의 경우는 어떨까요? 처리 스레드 종류에 대한 가정 - 소켓 이벤트 처리 6개 스레드 - 패킷 처리 1개..

1. 데이터를 동시에 쓰는 상황, 읽는 도중 값이 변경되는 상황, 읽는 도중 delete 되는 상황에 유의하라. -> 데이터를 동적으로 다뤄야 되는 상황 자체를 줄이는 것이 좋다. NULL 대신 NULL객체 처리를 선호하는 것이 멀티 스레드 프로그래밍에서 크래시를 줄이고 쉽게 예외 핸들링 할 수 있는 방법중 하나다. 2. 생성자 / 소멸자 호출 도중에 가상 함수를 읽지 않게 하라.-> 가급적 생성자 / 소멸자에선 로직 처리를 금하라. 실패 할 수 있는 동작은 생성자/소멸자에서 시도하지 않는 것이 좋다. 3. 동기화에 대해 주의하라. -> 어디서부터 어디까지 공유 데이터인지를 명확히하고, 그 이상의 접근을 막아라. 4. 스레드 마다 별도로 주어지는 공간 (스택), 모든 스레드가 공유하는 공간 (힙, 정적 ..