Programming is Fun

리눅스 쓰레드 만들기<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /?>

리눅스는 POSIX 쓰레드를 지원한다. 리눅스 쓰레드는 다음의 코드로 만들어진다:

리눅스에서 쓰레드 만들기

여기에서, t1은 쓰레드 ID를 받기위해 사용되는 매개변수이다. 두 번째 인자는 많은 스케쥴링 옵션을 지원하는 쓰레드 속성 인자이다. 우리는 여기서 디폴트 세팅을 사용할 것이다. 세 번째 인자는 쓰레드를 생성할 때 실행 될 서브루틴(subroutine)이다. 네 번째 인자는 서브루틴으로 전달된 포인터이다. 이것은 쓰레드나 새로 만들어진 쓰레드에 필요한 것을 위해 저장한 메모리를 지시할 수 있다.

리눅스 쓰레드는 서브루틴에서 리턴하거나 pthread_exit() 루틴을 호출하여 종료한다. 쓰레드가 가지고 있는 리소스는 부모 쓰레드가 pthread_join() 루틴을 호출할 때 회복된다. pthread_join()는 프로세스용 wait() 함수와 비슷하다.pthread_join()는 쓰레드에 의해 할당된 힙 메모리(heap memory)를 회복하지 않는다. 전역으로(globally) 할당된 메모리가 프로그램 또는 쓰레드에 의해 자유로워 져야 한다.

Windows 쓰레드 만들기

Windows 쓰레드는 Windows 프로세스를 만드는 것보다 훨씬 간단하다. 쓰레드를 만드는 데에는 리눅스에서 사용한 매개변수를 비롯하여 보안 디스크립터와 초기 스택 크기도 포함된다.

Windows에서 쓰레드 만들기

첫 번째 인자는 보안 디스크립터 로서 쓰레드 핸들이 상속 될 수 있을 지의 여부를 결정한다. NULL 은 이것이 상속될 수 없다는 것을 의미한다. 두 번째 인자는 스택 사이즈이다. 세 번째와 네 번째 인자는 서브루틴과 패스된 매개변수이다. 다섯 번째 인자는 플래그 인자이다. 쓰레드는 플래그가 CREATE_SUSPENDED로 설정될 때 중지 상태에서 만들어진다. 여섯 번째 인자는 결과 쓰레드 ID를 시스템에 저장한 위치를 가리킨다.

Windows 쓰레드는 호출된 서브루틴에서 리턴하거나 ExitThread() API를 호출하여 종료한다. 부모는WaitForSingleObject(threadid)를 호출하여 쓰레드를 정리하거나 WaitForMultipleObjects() API를 사용하여 다중 이벤트를 기다릴 수 있다.

이 번 칼럼에서 Edward G. Bradford 박사는 리눅스와 Windows 시스템에서 쓰레드 및 프로세스 관리에 초점을 맞추었다. 프로세스와 쓰레드의 차이점과 그들을 만들고 없애는 방법을 설명한다. 각자의 시스템에서 쓰레드 관리를 공부할 수 있는 적합한 프로그램도 만들어본다.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /?>

에 서 처음으로 프로그래밍 소켓을 살펴보고 단일 시스템 내에서 완전하게 작동하는 소켓 코드의 퍼포먼스도 측정했다. 측정 결과는 네트워크 전송 비율을 반영하지는 않지만 소켓용 최대 쓰루풋을 나타냈다. 이번 달 칼럼에서는 프로세스와 쓰레드를 생성하고 없애는 방법을 설명할 것이다. 쓰레드와 프로세스는 매우 유사하다. 리눅스에서, 쓰레드와 프로세스는 구별이 불가능하다.

프로세스(Processes)

프로세스는 리눅스와 Windows에서 모두 실행 프로그램을 뜻한다. Windows에서는 .exe 확장자가 있는 파일 이름이 실행파일이다. 프로세스는 소스 파일을 컴파일 하고 실행 파일을 생산함으로서 만들어진다. 컴파일 단계는 Windows와 리눅스 모두 비슷하다:

프로그램 컴파일하기

위 두개의 컴파일 결과는 create-pt2.exe (Windows)와, create-pt2 (리눅스)라는 실행파일이다.

프 로세스는 오픈 파일 핸들을 상속 받을 수 있다. Windows에서, 핸들이 작은 정수가 아니기 때문에 정확한 값은 알 수 없다. Windows에서 기존의 오픈 파일을 위해 핸들을 정확한 값으로 초기화 하는 것은 문서화된 프로시져가 아니다. 리눅스에서 파일 디스크립터(descriptor)를 20으로 설정하고 사용하는 것은 매우 쉽다.

일단 프로세스가 만들어지면 시작할 때 명령행에서 프로그램 이름을 타이핑 하면 된다. 리눅스와 Windows 모두 같다:

프로그램 실행하기

Windows 프로그램의 경우, .exe 서 픽스를 타이핑 할 필요가 없다. 프로그램이 실행권한이 있고 합법적인 Windows 바이너리 형식의 프로그램이라면 Windows는 모든 프로그램 이름을 실행 파일로서 인식한다. 따라서 나는 마이크로소프트 컴파일러의 아웃풋을 리눅스와 마찬가지로 create-pt2 라고 이름을 붙였다.

쓰레드(Threads)

쓰레드는 실행 콘텍스트(context)이다. 처음에 각 프로세스는 하나의 실행 콘텍스트를 갖는다. 이 실행 콘텍스트를 쓰레드라고 한다. 프로세스가 다른 실행 콘텍스트를 필요로 한다면 간단히 다른 프로세스를 만들 수 있다. 하지만 프로세스 생성은 프로세서 사이클과 메모리 사용의 관점에서 볼 때 사치스러운 일이다. 쓰레드는 다중 실행 콘텍스트를 만드는데 경량의(lightweight) 메커니즘을 제공하도록 되어있다. Windows와 리눅스는 한 쌍의 실행 환경을 제공할 목적으로 오퍼레이팅 시스템에서 쓰레드를 스케쥴링한다.

프 로세스와 쓰레드의 가장 뚜렷한 차이는 프로세스의 모든 쓰레드가 같은 메모리 공간과 시스템 정의의 "도구(facility)"를 공유한다는 점이다. 오픈 파일 핸들(파일 디스크립터), 공유 메모리, 프로세스 동기화 프리머티브(process synchronization primitives), 현재 디렉토리 등이 "도구"이다. 글로벌 메모리가 공유되고 새로운 메모리가 할당되지 않기 때문에 쓰레드를 만드는 것은 프로세스를 만드는 것보다 간단하고 빠르다.

아파치 1.x 대 버전과 아파치 2.x 대 버전의 차이점이 이것이 아닐까 합니다. 프로세스로서의 아파치와 스레드로서의 아파치의 성능차이..
아파치 2.x 대 버전부터는 멀티스레드 기능이 추가되었다는 것 아시죠^^

• 모든 OK Message는 +OK 로 시작
• 모든 Error Message는 -ERR로 시작
• Multi Line Message의 경우는 \n\r.\n\r로 종결 
• Input Message는 모두 \n\r이 들어가면 Server단에서 판단.

 #pragma omp parallel

{

    printf("Hello World ");

}

함수로 묶을 필요도 없고, 따로 프로시져로 떼어 놓고 쓸 필요도 없이 어디서나 OpenMP 지시어와 저렇게 블럭으로 묶으면 그 블럭에 해당되는 행위들이 쓰레드로 나뉘어서 표현을 하게 됩니다. 이렇게 하면 P4-HT 기술이 적용된 CPU에서는 위의 문장을 최소 두번 이상 실행하게 되지요. 또한 위와 같은 단순히 행위에만 관련된 병렬처리만 있는게 아닌, 값을 나눠서 처리하는 병렬처리도 가능하게 되었습니다.

#pragma omp parallel for for(int i = 1; i < 100 ; ++i)     x[i] = (y[i-1] + y[i+1])/2;

위와 같은 문장에서는 만일 프로세서가 4개라면, 첫번째 프로세서에서는 1부터 25까지의 연산을, 두번째 프로세서는 26부터 50까지, 이런 식으로 루프를 4개로 나누어서 프로세서 별로 처리 하게끔 합니다. 최적화의 기본중에 하나인 loop unrolling 방식을 아주 쉽게 표현 할 수 가 있게 되었습니다. 이외에도 여러가지 것들이 있는데, 보통은 쓰레드 하고 말을 하면 언제나 싱크 문제에 대해서 많이 걱정을 하게 됩니다. 그러나 아주 쉽게 여길 정도로 크리티컬 색션과 같은 항목을 위 처럼 간단한 pragma 세팅 만으로 처리 가능하도록 되어 있으니 너무 걱정 않해도 될 정도 입니다.

스레드 Windows API 함수를 클래스로 래퍼(Wrapper)해서 쓰는 방법에 대해 소개하겠습니다. MFC에 있는 객체 스레드에서 워커 스레드로 구현할 때 MFC 객체 스레드는 너무 무겁게 느껴질 것입니다. 그 대안으로 객체 스레드를 구성해 보았습니다. 이 스레드는 워커 스레드용으로써, 이 스레드를 잘 활용하면 가장 깔끔하고 간단하면서도 강력하게 구현될 것입니다.

  객체 스레딩 기법의 재사용성에 맞추어 구현해 보도록 하겠습니다. 기반 클래스(Base Class)를 CThread라고 가정하고 다음과 같이 구현합니다.

  객체 스레딩 기법의 객체 스레드 선언 부분은 다음과 같다.

class CThread 

{

public:

    CThread();

    virtual ~CThread();
    virtual void Create();

    virtual void Stop();
    BOOL IsRunning() { return m_hThread != NULL; } const
    virtual DWORD OnThreadProc() = 0;

    static DWORD WINAPI ThreadProc(LPVOID lpParam);
    static int GetRefCount() { return m_nRef; } const

    int GetIndex() { return m_nIndex; } const
protected:

    HANDLE m_hThread;

    DWORD m_dwThreadId;
private:

    static int m_nRef;

    int m_nIndex;

};
  

int CThread::m_nRef = 0;
//////////////////////////////////////////////////////////////////////

// Construction/Destruction

//////////////////////////////////////////////////////////////////////

CThread::CThread()

{

    m_nIndex = m_nRef++;
    m_hThread = NULL;

    m_dwThreadId = 0;

}
CThread::~CThread()

{

    m_nRef--;

}
//////////////////////////////////////////////////////////////////////

// Implementation

//////////////////////////////////////////////////////////////////////

void CThread::Create()

{

    m_hThread = ::CreateThread(0, 0, ThreadProc, this, 0, &m_dwThreadId);

}
void CThread::Stop()

{

    while (::WaitForSingleObject(m_hThread, 0) != WAIT_OBJECT_0)

        Sleep(50);
    CloseHandle(m_hThread);

    m_hThread = NULL;

    m_dwThreadId = 0;

}
DWORD WINAPI CThread::ThreadProc(LPVOID lpParam)

{

    CThread *pThread = (CThread *)lpParam;

    ::ExitThread(pThread->OnThreadProc());

    return 0;

}

이제 객체 스레드의 선언과 정의 부분을 구현하였고, 이 기반 클래스(Base Class)로부터 상속받아 예제 프로그램을 작성해 보도록 하겠습니다. 다음의 예제 프로그램은 파일을 삭제하는 객체 스레드입니다.

class CDeleteFileThread : pulbic CThread

{

public:

    
CDeleteFileThread();

    virtual ~CDeleteFileThread();
    void SetPath(LPCTSTR);
protected:

    virtual DWORD OnThreadProc();

   

protected:

    
TCHAR m_szPath[MAX_PATH];

};
CDeleteFileThread::CDeleteFileThread()

{

    memset(m_szPath, 0, 
MAX_PATH*sizeof(TCHAR));

}
CDeleteFileThread::~CDeleteFileThread()

{

}
void CDeleteFileThread::SetPath(LPCTSTR lpcszPath)

{

    
_tcscpy(m_szPath, lpcszPath);

}
DWORD CDeleteFileThread::OnThreadProc()

{

    SHFILEOPSTRUCT shfo = 
{0};

    shfo.wFunc = FO_DELETE;

    shfo.pFrom = m_szPath;

    
SHFileOperation(&shfo);
    return 0;

}

1)  TCP 연결관련 상태

• RFC 793문서에 나온 기본적인 TCP 연결 과정

      TCP A                                                      TCP B
  1.  CLOSED                                                     LISTEN
  2.  SYN-SENT    --> < SEQ=100>< CTL=SYN>                   --> SYN-RECEIVED
  3.  ESTABLISHED <-- < SEQ=300>< ACK=101>< CTL=SYN,ACK>     <-- SYN-RECEIVED
  4.  ESTABLISHED --> < SEQ=101>< ACK=301>< CTL=ACK>         --> ESTABLISHED
  5.  ESTABLISHED --> < SEQ=101>< ACK=301>< CTL=ACK>< DATA>  --> ESTABLISHED

LISTEN      : 데몬이 요청을 발을 수 있도록 연결 요구를 기다리는 상태
  즉, 포트가 열려있음을 의미. http(80), mail(25), ftp(21), telnet(23) 등
  위에서 포트 25(mail)이 메일을 받을 수 있도록 열려 있는 상태
  윈도우즈에서는 LISTENING으로 표시
SYN_SENT    : 로컬에서 원격으로 연결 요청(SYN 신호를 보냄)을 시도한 상태
SYN_RECV    : 원격으로 부터 연결 요청을 받은 상태
  요청을 받아 SYN+ACK 신호로 응답은 한 상태이지만 ACK는 받지 못했다.
  netstat로 확인할 때 SYN_RECV가 상당히 많다면 TCP SYN 플러딩(Flooding) 공격일
  가능성이 있다.
  윈도우즈와 솔라리스에서는 SYN_RECEIVED으로, FreeBSD는 SYN_RCVD으로 표시
ESTABLISHED : 서로 연결이 되어 있는 상태
  위에서 192.168.123.10의 포트 32794과 218.xxx.xx.xx의 포트 22(ssh)이 서로
  연결되어 있는 상태

2) TCP 종료관련 상태

* 정상적인 연결 종료 과정

      TCP A                                                   TCP B

  1.  ESTABLISHED                                             ESTABLISHED
  2.  (Close)
      FIN-WAIT-1  --> < SEQ=100>< ACK=300>< CTL=FIN,ACK>  --> CLOSE-WAIT
  3.  FIN-WAIT-2  <-- < SEQ=300>< ACK=101>< CTL=ACK>      <-- CLOSE-WAIT
  4.                                                         (Close)
      TIME-WAIT   <-- < SEQ=300>< ACK=101>< CTL=FIN,ACK>  <-- LAST-ACK
  5.  TIME-WAIT   --> < SEQ=101>< ACK=301>< CTL=ACK>      --> CLOSED
  6.  (2 MSL)
      CLOSED                                                      

FIN_WAIT1   : 소켓이 닫히고 연결이 종료되고 있는 상태. 원격의 응답은 받을 수 있다.
  솔라리스에서는 FIN_WAIT_1로 표시
FIN_WAIT2   : 로컬이 원격으로 부터 연결 종료 요구를 기다리는 상태
  솔라리스에서는 FIN_WAIT_2로 표시
CLOSE_WAIT  : 원격의 연결 요청을 받고 연결이 종료되기를 기다리는 상태
  원격으로 부터 FIN+ACK 신호를 받고 ACK 신호를 원격에 보냈다.
TIME_WAIT   : 연결은 종료되었으나 원격의 수신 보장을 위해 기다리고 있는 상태
  이 상태를 특히 자주 보게되는 Apache에서 KeepAlive를 OFF로 해둔 경우,
  Tomcat 서버를 쓰는 경우 등
LAST_ACK    : 연결은 종료되었고 승인을 기다리는 상태
CLOSED      : 완전히 연결이 종료된 상태

※ 위의 FIN_WAIT1, FIN_WAIT2, CLOSE_WAIT 3개 상태는 연결 종료를 위해 서로간에
   신호를 주고받는 과정에 나타나는 상태로 이해하면 된다.
   종료 요청을 한 곳에서는 FIN_WAIT1, FIN_WAIT2, TIME_WAIT 상태가
   종료 요청을 받는 곳에서는 CLOSE_WAIT, LAST_ACK 상태가 표시된다.

3) 기타

CLOSING     : 연결은 종료되었으나 전송도중 데이타가 분실된 상태
UNKNOWN     : 소켓의 상태를 알 수 없음

솔라리스의 netstat 명령에서는 다음 2개의 상태를 더 표시한다.

IDLE        : 소켓이 열렸지만 binding 되지 않은 상태
BOUND       : listen이나 연결을 위한 준비 상태

※ 참고 문서  
- netstat 맨페이지(linux, solaris)
- RFC 793 ( http://www.ietf.org/rfc/rfc0793.txt )

web page 돌아다니다가 간단한 자료 조사 

http://www.windowsnetworking.com/art...irtual-PC.html

: Sysprep을 이용한 virtual pc의 배포 방법 제시

http://msdn.microsoft.com/en-us/libr...92(VS.85).aspx
: Hyper-V WMI document information

http://blogs.msdn.com/virtual_pc_guy...h-hyper-v.aspx
: Hyper-V PowerShell & VBScript create sample api

http://blogs.msdn.com/mikester/archi...-in-winpe.aspx
: Using the Hyper-V integration components in WinPE