Thread design에 대한 이해는, 기본적으로 잠금 정책에 over head를 이해하고 있느냐에서 출발한다고 생각합니다.

잠금 기반 프로그래밍은, 자주 사용하는 코드가 잠기게 될수록 성능이 수직 하향합니다.

대기 하느라, 제대로 된 퍼포먼스를 낼 수 없다는 얘기죠.

그렇게 하지 않기 위해, 객체 간에 잠금에 신경쓰지 않게끔, 객체 간 접점을 줄여주어야 합니다.

좋은 Thread design의 목표는 어떻게 잡아야 할까요?

접점 최소화

손쉬운 비동기 처리

의도한 대로 순차 처리 (순서가 중요한 동작의 순서 보장)

디테일하게 나열하자면 얼마든지 많겠지만, 저는 위 세가지 목표가 보장된 기반 코드는, 컨텐츠 구현 시에 필요한 요구 사항을 다수 충족 시킬 수 있습니다.

이런 문제가 현세대 멀티스레드 프로그래밍의 최선이라고 여겨졌는지, 많은 솔루션이 이런 니즈를 충족시키는 데에 최적화되서 개발이 되었습니다.

node.js는 무거운 작업마다 비동기로 던지고, 그 결과 값을 바탕으로 진행할 다음 작업을 지정함으로써 잠금과 순서를 고민하지 않는 프로그래밍을 유도하고 있습니다.

만약 무거운 작업을 비동기로 처리하지 않는다면, 프로그래머의 실수라고 규정 짓는 가이드라인을 제시했습니다.

erlang도 마찬가지입니다.

기본적으로 메시지로만 통신을 유도하면서, 각 작업 간에 겹치는 상황을 제거함으로써, 잠금을 고민하지 않도록 했죠.

이렇게 할때의 언어에 구애 받지 않는 핵심은, 작업마다 독립적으로 동작할 수 있어야 한다는 점입니다.

로직을 작성하는 데에 있어서, 이 객체마다 잠금을 걸었다 풀어주는 과정은 잠재적 성능 저하 지점을 만드는 과정이라 볼 수 있습니다.

아무리 측정을 자주 하는 팀이라 할지라도, 기존에 (논리적으로도, 성능 적으로도) 잘 동작하던 코드가 병목이 될 수 있는지 여부는 의심을 덜하기 마련이기 때문이죠.

그런 잠재적 우려 지점을 변수가 추가될 때 마다 늘리는 방식은 결코 좋다고 보기 어렵다는 결론에 도달해, 현재의 모델이 최선이라고 느끼는 상황이죠.

애초에 작업들이 모두 작게 쪼개져 있고, 그간에 영향을 받지 않는다고 확신 할 수 있다면 당연하게도 대기 없는 비동기 처리가 가능해집니다.

로직을 작성하는 사람이 고민해야 될 대상중에 순서만이 남은 것이죠.

작업들을 비동기로 분리하고 난 뒤의 로직의 순서 조절은 상대적으로 쉬운 문제가 됩니다. 결합도를 고민하지 않아도 되는 상황이 되어버렸기 때문에, 순서 보장 기능을 라이브러리나 프레임워크 단에서 지원 (혹은 스크립팅으로 조절) 해주기 쉽고, 그렇지 않은 경우에 구현하는 문제도 순서 보장 작업끼리 같은 큐를 사용하게만 해줘도 되는 것이죠.

요약하자면 비동기 프로그래밍에서의 성능을 장점으로 삼는 다수의 언어와 프레임워크가 내린 합리적인 선의 비동기 프로그래밍은, 작업간 결합도를 줄인 후, 작업을 병렬로 수행해 성능 향상을 노리는 쪽으로 가고 있습니다.

제 생각도, 합리적인 선의 선택이라고 보여집니다. 극한의 성능도 중요하지만, 로직 작성의 난이도를 낮추는 것도 중요한 문제거든요. 실수할 여지를 줄이는 장점도 물론 옵션이겠고요.

지금까지 thread-design에서의 잠금 최소화 프로그래밍에 대해 알아보았습니다.

https://nssm.cc/

 nssm-2.24.zip

rails 서비스화에 사용한 배치 파일 예제입니다. 아주 간단해요.

윈도우 서버의 경우 권한 문제에 빠질 수 있는데, 이 경우 아래 링크처럼 대처하세요.

http://elky.tistory.com/561

Install_web.bat

pushd %~dp0

@echo off

%cd%\nssm.exe install %1 C:\RailsInstaller\Ruby2.1.0\bin\rails.bat "s -p 8000 -e production"

%cd%\nssm.exe set %1 AppDirectory %cd%

Start_web.bat

pushd %~dp0

@echo off

net start %1

Stop_web.bat

pushd %~dp0

@echo off

net stop %1

Uninstall_web.bat

pushd %~dp0

@echo off

net stop %1

nssm.exe remove %1 confirm

service_wrapper.zip

콘솔 프로그램을 service로 등록해주는 instsrv, srvany의 wrapping batch 파일입니다.

사용법은 

install.bat "서비스명" "실행파일경로" "인자"

uninstall.bat "서비스명"

입니다.

제가 프로그래밍을 처음 배울 때의 CLI 프로그래밍과 WIN32 프로그래밍으로 넘어왔을 때 큰 괴리를 느꼈습니다.

그 이유는 바로 EVENT-DRIVEN(message based)프로그래밍 때문이었죠.

현재는 reactor라는 패턴이란 이름으로 더 알려진 이 메시지 기반 프로그래밍은, DOS 시절의 동기 프로그래밍에 익숙한 많은 프로그래머를 괴롭게 했습니다.

message라는걸 왜 굳이 만들어 처리하는가….에 대해 저는 그 당시 이해하기 어려웠습니다.

당시만해도, 윈도우 메시지를 굳이 처리하지 않고도 여러 작업이 가능했기 때문이죠.

예를 들어 GetAsyncKeyState (http://msdn.microsoft.com/ko-kr/library/windows/desktop/ms646293(v=vs.85).aspx) 같은 함수로도 얼마든지 키 입력 처리가 가능했고, 마우스 입력도 마찬가지였죠.

굳이 왜 메시지 핸들러 코딩을 왜 해줘야 하는지 이해가 잘 안 갔어요. 특히나 윈도우 기본 컨트롤들을 사용하지 않았기 때문이기도 할 겁니다.

이 때가 98년 경이었는데, COM 기반의 메소드를 통해 초기화하던 Direct-X가 이해 안갔던… (그 당시엔 COM이 뭔지도, 왜 저렇게 복잡하게 포인터 캐스팅하는지도 이해가 어려웠습니다) 시기였습니다.

코어도 한 개이던 시절이라, multithread  프로그래밍은 n개의 CPU를 꽂아 쓰는 서버나 슈퍼 컴퓨터 사용자들에게나 필요한 걸로 치부 되기도 했습니다.

헌데…그 어렵디 어렵다던 multithread 프로그래밍이 사실은 WIN32 프로그래밍에선 각종 API를 통해 이루어지고 있었고, 메시지 핸들링 코드는 다른 thread (다른 프로세스에서 오는 메시지도 있지만)에서의 처리 결과를 전달하는 코드이기도 했다는 걸 한참이 지나서야 알게 됐습니다.

더 깊게 알아내지 못한 제 잘못도 있지만, 책과 PC통신을 제외하곤 정보를 얻기 힘든 당시 상황을 감안하면, 좀 더 친절하게 설명해주지 못한 당시 WIN32 프로그래밍 입문서들의 문제도 있습니다.

자! 여기서 핵심은, WIN32 어플리케이션을 만들어온 과정이 사실은 multithread 프로그래밍을 해왔다라는 점이에요. 우리가 몰랐을 뿐이죠.

모를 수 있었다는 것은, 사실 WIN32 메시지 핸들러를 통한 thread  모델이 안정적이고, 잘 디자인된 thread design중 하나라고 볼 수 있습니다. WIN32 메시지 핸들링 방식은 메시지 루프를 통해 비동기 작업들을 처리해야 될 때에만 양보하고 다시 주 thread 루프로 돌아오게 해주었던 안정적인 thread design과 API를 구성했죠.

이로써, multithread에 대한 이해 없이, 그리고 thread 동기화에 신경 쓰지 않고도 비동기 프로그래밍을 할 수 있었습니다.

그렇습니다! 우리는 WIN32 메시지 기반 프로그래밍을 통해 Reactor thread design을 경험한 것입니다!

정리하자면, thread design이란 다음 요구사항을 충족해야 한다고 보시면 됩니다.

1. 객체를 lock을 신경 써야 될 부분, 그렇지 않은 부분을 명확히 규정
   -> 프레임워크단에서만 신경쓰도록 구현하는 것을 권장하지만, 개체 단위 lock이 정책인 경우도 있습니다.
   -> 개체 단위 lock으로 구현한 경우에는, 코딩 난이도 상승, 병목 지점 감지도 어려워질 뿐더러, 데드락 위험성도 높아져 좋지 않은 디자인이라고 봅니다.
   
   
2. API 사용법만 준수하면 최대한 많은 코딩 영역에 thread 동기화를 고민하지 않도록 하는 것
   -> 이 부분이 사실 핵심인데, thread design이 잘 되어 있을 수록, 성능도 만족하면서 유지 보수 난이도가 급격하게 낮아진다고 보시면 됩니다.
   
   
3. Blocking 동작이나, 반복작업, 병렬 수행이 필요한 작업등을 지원하기 위해 비동기 작업을 위임하거나, 분산할 수 있는 기능
   -> thread pool을 통한 작업 분배, open MP등으로 지원된 병렬 코드 수행등을 떠올리시면 좋습니다.

WIN32 메시지 기반 모델에서는 병렬 작업을 위한 분산 기능은 미흡했으나, (시기적인 부분을 감안해 줘야 된다고 생각합니다만) 그 이외의 요구 사항은 충족합니다.

이렇듯 thread design이란 먼 곳에 있지 않았습니다!

1.Critical Section

2. 동기화 대기 함수

3. Mutex (MUTual EXclusion)

* 포기된 뮤텍스

 만약 뮤텍스를 소유하고 있는 쓰레드가 ExitThread나 TerminateThread로 비정상적으로 종료시켰을 경우 강제로 뮤텍스를 시그널 상태로 만들어준다. 그러므로 대기 중인 다른 쓰레드에서 뮤텍스를 가지게 되는데, WaitForSingleobject() 의 리턴 값으로 WAIT_ABANDONED 값을 전달 받음으로써 이 뮤텍스가 정상적인 방법으로 신호상태가 된 것이 아니라 포기된 상태임을 알 수 있다. 중복 소유 뮤텍스를 여러 번 겹쳐서 사용했을 경우 데드락과 같은 상태에 빠질 수도 있을 것이다.

4. Semaphore

5. Event

출처:: http://blog.daum.net/thermidor/5173637

IT 얘기는 아닌거 같은데... 크게 공감되네요.