지금 간단한 시스템 정지 프로그램을 짜고 있구요....
대충의 소스는 다음과 같아요.....


unsigned _stdcall thread(void *arg)
{

while(1)
{

}

return 0;

} 
int main()
{
int i;

for(i=0;i<3000;i++)
{
_beginthreadex(NULL, 0, thread, 0,0, NULL);
}

getch(); 
return 0;

}

물론 setting에서 debug multithread는 해주었구요....
근데 에러는 없는데...시스템이 멈추지는 않네요......

근데..._beginthread()를 쓰면 잘 되요...
그러니까 시스템이 잘 멈춘다는 얘기지요.....
왜 그런건가요....
지금 이 소스는 프세12월호에 있는 소스거든요..... 
서버 프로그램을 하다가 쓰레드 사이의 락때문에
고생 하시는 분들이 계신 것 같군요.
저도 쓰레드를 쓰지 말자고 주장 하는 사람 중에
한 사람 이고 또 그렇게 개발 하고 있습니다.
제 생각에는 한 클라이언트의 요청에 그리 많은 프로세싱
타임이 걸리지 않는다면은(많은 프로세싱이나, 디스크 I/O가
많다던가 하면은 애기가 달라 지겠지만서도) 굿이 어렵게 쓰레드를
쓸 필요가 있을가란 생각이 드네요..
하지만, 쓰레드를 쓰시는 분들은 나름대로 타당한 이유가 있겠죠?
쓰레드를 꼭 써야 하는 이유가 있다면 저좀 알려 주세요..
어쩌면, 그게 정답 일 수가 있으니깐요.. 그러면 난 프로그램 다시
짜야 하는데....

지금, 후배들과 간단한 머드 게임 형식의 프로그램 하나 짜고 있습니다.
어쨋튼, 한달안에 베타테스트 할 예정이니 많이 참여해 주시면 감사 
하겠습니다.
다른 분들 말씀을 들어보면은 Server가 잘 죽는 다던데 걱정이네요..
제가 서버 담당인데...
지금 까지 잡담 이었습니다.

----jadoo 
1. CPU가 남기 때문이죠.
멀티 씨피유를 가진 컴에서 싱글 쓰레드로 돌리면
씨피유 낭비가 되겠죠. 물론 OS가 잘 지원해 주어야
겠지만요.
2. 현실과 비슷한 구조로 접근할 수 있습니다.
현실은 여러가지 일이 복잡하게 돌아갑니다.
물론 게임도 마찬가지죠. 이런것들을 프로그램화
하기 위해 구조를 잡는데 쓰레드가 있으면 한가지더
가능성이 생깁니다. 물론 멀티 프로세스로 프로세스간 통신을
해도 비슷하게 구현되지만 더 복잡하고 힘들죠.
국민학교때 겔러그 비슷한 오락을 베이직으로 8bit컴으로 짜보려
하던 기억이 생각 나네요. 제 비행기가 움직일때 적기가
안움직였거든요 -_-; 한참 지나서야 그문제에 대한 해결책을 찾았던거 같구요.
근데 쓰레드를 쓴다면 더 쉽게 구조를 잡을 수가 있습니다.
한가지 가능성이 더 생긴다는 거죠. 부하 한명을 죽노동을 시킬수도 있지만
여러명이 협동해서 일을 하게 한다고나 할까요.
물론 쓰는데는 좀 까다롭지만 협동해서 하는 만큼 작업이 단순해 집니다.
또한 어떤 부분이 더 힘들면 그부분에 부하들을 더 투입하면 되겠죠?
마찬가지로 해당일을 하는 쓰레드의 갯수를 늘려주면 씨피유가 허용하는
만큼 효율이 늘어나게됩니다. 예를들면 유저의 패킷을 쓰레드로 처리한다면
그부분에서 자꾸 병목이 생긴다면 그쪽 쓰레드의 수를 늘려주면 됩니다.
물론 이렇게 해서 해결이 안되는 경우도 있습니다. 그땐 기계를 갈아야겠죠 ^^;

단점을 든다면
1. 공유 자원에 대한 관리가 필요합니다.
쓰레드간에 공유하는 자원에 대해 관리가 필요합니다. 이부분이 많은 어려움을
낳는 부분이고 버그의 온상입니다. 근데 자꾸 쓰고 당하다 보면 익숙해 집니다.

2. 쓰레드 자체도 한계가 있습니다.
쓰레드가 만능은 아닙니다. 필요할때 마다 막쓰다 보면 
한계가 생기죠. 숫자에 대한 한계입니다. 초기에 유저가 들어오는 만큼 쓰레드를
만들어도 되지 않겠는냐는 마음을 가졌다가 그 마음을 지우도록 한것이 바로
이 이유 때문입니다.

3. 구조가 않좋거나 많아지면 오히려 비효율적입니다..
쓰레드의 구조가 않좋을 경우 싱글보다 더 걸린다고 합니다.
이건 데이터 락하고 푸는 시간때문이죠.

결론은 쓰레드를 쓰든 안쓰든 거기에 맞는 구조로 설계가 되야겠죠.
물론 말은 쉽습니다 하하하하. ^^;
구현을 실제로해보면 어려움도 많고 막히는 부분도 많지만
여러가지 재미있는 점이 많습니다.
하지만 결국 가장 중요한건 제 기능이 제대로 안전하게 돌아가느냐죠..
__
이경만 
PS.누구 테크노 춤바람에 빠진 몬스터를 진정시키는 방법 아시는분?

제가 쓰레드를 쓰는 이유는 다음과 같습니다.

1. 리소스가 남는한 가능한 동시 수신 처리를 할 수 있다.

클라이언트 1에서 처리 시간이 제법 긴 요청(예를 들어 로그온)을 처리하는 동안,
이미 로그온한 클라이언트 2에서 처리 시간이 짧은 요청(예를 들어캐릭터를
움직였다)을 처리할 때가 왔다고 가정해 봅시다. 싱글 스레드라면, 오토마타 방식으
로
수신 처리를 구현하지 않은 이상, 클라이언트 2의 처리는 클라이언트 1의 처리가 끝
난
다음에야 가능하겠죠.
하지만, 클라이언트 1의 요청과 클라이언트 2의 요청을 서로 다른 스레드에서
처리한다면, 공유해야 하는 리소스가 없는 이상, 동시 수신 처리가 가능하겠죠.

오토마타를 이용한 수신 처리는 싱글 스레드로도 동시 수신 처리에 다소 가깝게 접근
───────────────────────────────────────
2. 프로세싱보다, 디바이스 출력 대기를 위한 시간이 비교적 많을 때 유용하다.

소켓 수신 대기, 데이터베이스 트랜잭선 대기, 다른 분산 서버 파트의 처리 응답 대
기
등, 서버의 규모가 커지면, CPU 점유 말고도, 대기 시간이 길어지는 경우가 많습니다
.
특히, 제 경험상, 멀티 서버에서는 그런 양상이 여기 저기서 생기는 것 같습니다.
짬짬히 노는 CPU..그냥 냅두긴 아깝죠? 이럴 때, 남는 CPU 타임에 다른 스레드를
붙여서 처리해 보세요.

..하지만, 역시, 프로그램을 작성하다 보면, 스레드가 하나일 때가 훨씬 편한 구석이

많습니다. 그래서, 저도 웬만하면 싱글 스레드로 처리를 합니다. NPC 움직임 처리,
월드 진행 등은 그렇게 하고 있죠. 
스레드 풀링이란, 여러개의 스레드를 돌리다가, 클라이언트 요청 등이 들어오면,
'잠자는' 스레드가 있는지 찾아보고, 있으면 아무거나 하나 깨워서 그게 그 요청을
처리하게 만듭니다.

스레드 풀링을 구현하는 방법은.. 사실, "니 맘대루 해라"지만, 윈도에서는 그걸
구현하기 위한 몇가지 API를 제공하고 있죠.

윈도95이상에서는, File Overlapped I/O를 써서 스레드 풀링을 만들 수 있습니다..
단지, 좀 불편한게 흠이지만. 그런데, NT에서는 I/O Completion Port를 써서 좀 더
간편하게 스레드 풀링을 구현할 수 있고, 좀 더 간편할 것이라 짐작되는,
윈도2000에서 지원하기 시작하는 QueueUserWorkItem등을 사용해서 스레드 풀링을
만들 수도 있습니다.

제가 만든 게임-Cafe9 서버는 I/O Completion Port를 이용해서 스레드 풀링을
합니다. NT에서는 그래도 스레드 풀링 큐다운 API이기에, 선택을 한거죠. 
CPU갯수*2개만큼의 스레드 풀을 마련해놓고 처리하기에, 듀얼 CPU를 가진 컴의 경우

동시 처리할 수 있는 요청 갯수가 4개인 셈이죠.

학규님이 언급한 QueueUserWorkItem API를 찾아봤는데, 좀 더 확장된 기능이
괜찮더군요. 하지만, 아직은 윈도2k가 많은 버그가 있다고 하기에, 당장 서비스를
해야 하는 마당에서 버그있는 윈도2k를 쓰면 탈이 많을 것 같아서, 그냥 I/O
Completion Port를 쓰고 있습니당.

그건 그렇고, 제 경험상 내린 결론은,

1-서버 머쉰의 CPU가 4개 이상이다.
2-분산 처리가 안된다.
3-사용자당 처리 응답 시간이 긴 경우가 많다.
4-멀티프로세스 보호를 해야 하는 리소스의 구별 단위가 명확하다. 
5-CPU 이외의 다른 자원, 예를 들면 외부 데이터베이스나 웹 서버 등을 많이
사용한다.

같은 이유가 없는 이상, 굳이 스레드를 여러 개 두는건 그다지 좋지 않다고 봅니다.

프로그램도 복잡해지고, 처리 성능도 싱글스레드만 못할테니까요.

근데, 왜 나는 스레드를 여러개 돌리느냐? 그 이유는.. 위에 써놓은 이유 중 3,4,5가

해당되기 때문이죠. 헐..

스레드 풀링.. 천하무적은 아닙니다. "우리한텐 꼭 필요한 것인가?" 를 먼저 검토한

다음에 사용 여부를 선택하시기 바랍니다. 게다가, 스레드 풀링을 하는 방법도 앞서
언급했지만, 디자인도 여러가지고, 심지어 제공하는 API도 여러가지입니다. 게다가,

각각의 API가 일장일단이기에, 특별한 최상의 선택도 없습니다. 그러니까, "우리한텐

어떤 방식이 필요한가?"가 다음 검토 사항이겠죠.

껨서버 프로그래머들 화이팅~~

PS. 병특 전역(?) 일주일도 안남았똬~~~ 
아래 글들을 읽어보니까 클라이언트 하나당 스레드를 하나씩 주는 건

비효율적이라고 되어 있네요..

그리고 좋은 방법으로 각 작업마다 쓰레드를 주는 것이 있다고 하는 데요..

그럼 이제 질문인데요..

버클리 소켓으로도 이게 구현이 가능 한가요?

윈속이라면, non-blocking이니까

클라이언트 핸들(TCP)마다 WSAEventSelect같은 걸 걸어두면 된 것 같은데요..

제가 궁금한 건 Berkley소켓에서는 
어떻게 이것을 구현하죠??

Berkley 소켓은 recv()같은 경우 blocking되서

프로토콜이 오든지 아니면 에러가 날 때까지 기다려버리잖아요..

그러면 다른 클라언트에서 오는 프로토콜은 당연히 못 받을 거고..

Berkley 소켓으로는 아예 불가능 한가요??

그냥 궁금해서 질문드려 봅니다.

안녕하세요? 학규입니다.

나름대로 자료를 좀 찾아보고 해서 모델을 세워봤는데, 제가 제대로 생각한건지

미리 여러분의 조언을 좀 구해볼까 해서 써 봅니다. 잘못된 점이나 더 개선의

여지에 대해 조언해주셨으면 감사하겠습니다.

일단은 NT 기반으로 짜기로 했고, 멀티 쓰레딩 모델로 나가기로 했습니다.

멀티쓰레딩 모델을 택하기로 한 이유는, 차후에 2 개 이상의 CPU 를 장착한

서버머신을 사용할 계획때문입니다.

일단 3 가지의 쓰레드를 돌릴 생각입니다. 
첫번째는 Listener 쓰레드입니다. 여기서는 Listening socket 을 이용해서

서버에 접속하는 사용자에 대해 접속에 대한 클래스 (CClient) 을 만들어서

CClientList 에 등록시켜주는 일을 합니다.

두번째는 ClientList 쓰레드입니다. 여기서는 ClientList 에 등록된 접속

소켓마다 Recv 를 Overlapped 로 실행해주는 역할을 합니다. 해당 소켓에서

무언가 데이타가 와서 이벤트가 발생하도록 유도하는 역할을 하게 됩니다

세번째는 실제로 각각의 이벤트에 대해 처리를 해주는 Worker 쓰레드입니다 
Listener 와 ClientList 는 각각 1 개의 쓰레드인 반면, Worker 는 n 개의

쓰레드가 돌아가고 있게 되어있습니다. 처음에는 쓰레드의 갯수를 유동적

으로 조절하는 쓰레드풀링을 할 생각이었지만, 어차피 머신별 최대제한인원의

테두리안에서 짜는건데 접속자가 적을때의 퍼포먼스를 증가시키는건 별 의미가

없지 않을까 하는 생각이 들어서 쓰레드의 숫자는 서버를 시작시킬때에 정하게

하도록 하였습니다. 이 Worker 쓰레드들은 대부분 Wait 상태에 있다가 ClientList

에서 실행한 Recv 가 완료될 시점에 깨어나서 패킷을 parsing 하고, 필요한

작업을 한 다음, 결과를 클라이언트측에 Send 하고 다시 Wait 상태로 돌아가게 
됩니다.

아직 제대로 구현을 해본 것이 아니고, 그냥 생각만으로 정리해본 것이라서

제가 맞게 생각한 것인지 어떤지 모르겠습니다. 특히 Overlapped I/O 를 사용해서

각각의 Client 에게 Recv 를 시켜놓는다는 개념이 옳은건지 틀린건지 모르겠군요

그 외에 동기화의 문제라던가 등등의 문제가 있을듯 한데, 이에 대해 다른분들의

지적을 부탁드리겠습니다

학규
neolith
현재 win32 network programming 을 보고 있습니다.

그런데 스레드 동기하라는 말이 나오는 군요.

"한 프로세서에 소속된 모든 스레드는 하나의 주소 공간을 공유하므로 프로세서의
모든 정적 데이터를 접근할 수 있으며 윈도우 핸들, GDI 객체, 파일 핸들, 동기화

객체 등 프로세서가 소유하는 모든 객체도 공유하게 된다. 스레드끼리는 매우 밀접

한 관계를 가지게 되므로 여러 프로세스가 사용하는 데이터 아이템이나 객체에 대

한 접근을 동기화해야 한다. (5장 참조)" - 80페이지

제 5장의 내용은 뮤텍스나 이벤트 같은 내용이더군요. 그런데 제가 궁금한 것은

게임 서버에서 여러 스레드가 데이터 아이템이나 객체에 대한 접근을 동기화한다

는 개념이 아! 이거 하면서 와닫지 않습니다.

게시판에서 동기화를 조회하니 게임 플레이의 동기화가 많이 토론되었고 쓰레드의
동기화는 자세한 내용이 없더군요. 서버 플밍에서는 중요하다는 추측이 드네요.

동기화란 말부터 막연한 것이 사실입니다. 동기화, 비동기화, 영어사용자들은 현

실감있게 사용하는 지 모르지만 한국어 번역은 영 느낌이 안오는 군요.

네떡에 뛰어든 초보들을 위해서 동기화, 쓰레드 동기화를 쉬운 비유나 예를 들어

강의해주시면 감사하겠습니다. 
음.. 뭐 동기화를 해야하는 이유야 수도 없이 많겠지만..

간단한 예를 들어보겠습니다.

우리가 어떤 게임 서버를 제작하는데 User들을 Thread pool로 관리하도록

설계를 했습니다. 아시다시피 Thread는 Data는 공유하고 Processing은 동시에

하지요.

A라는 User와 B라는 유저가 각기 다른 Thread에 배정되었습니다.

그런데 A, B가 거의 비슷한 장소에서 거의 다죽어가는 Monster를

만났습니다. 둘은 거의 동시에 칼을 휘둘렀지요. 
A, B 에서 DoAttack() 이라는 함수를 실행했습니다.

두개의 쓰레드가 동시에 이 함수를 부른것이지요.

DoAttack()함수는 만약 공격받은 녀석이 죽었으면 아예 메모리에서 삭제하도록

만들어져 있었습니다.

A, B 유저의 쓰레드가 거의 동시에 이 함수에 진입해서 둘다 진행중일때..

둘중의 하나가 Delete를 하고 나면 나머지 쓰레드도 Delete를 하려고 하겠지요?

거의 찰나의 순간에 두번째 쓰레드가 없애려고 한 메모리가 쓰레기값이 
되어버린거지요.. 결국 Access violation이 일어나겠지요?

그래서 이런 상황을 방지하기 위해서 Thread에 안전장치를 답니다.

예를 들어 DoAttack()함수의 Delete하는 부분 전후에다가 Lock/Unlock 등을 달아서

두 쓰레드가 동시에 접근하지 못하도록 하는거지요.

둘중 미세하게 먼저 도착한놈이 일을 다 끝내면 두번째 쓰레드가 기다리다가

코드에 진입하는거지요.

뭐 이런 거 말고도 시간 동기화라던지 이런저런 이유들이 많이 있겠지요..

여튼 도움이 되었으면 좋겠네요 
Windows NT가 설치될 수 있는 Server중에 Machine상의 의미에서 3개이상의
CPU을 장착할 수 있는지요?
전 Dual CPU(그것두 risk칩이 아닌 펜티엄시리즈)밖에 본적이 없어서리^^ 

NT 에서도 가능 합니다. 16개 까지 되던가? 아마.. 음..

-비엽