Q&A와 스터디
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:5507point (81%), 레벨:7/30"){kind=icon}
1ststory![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:0point (0%), 레벨:0/30"){kind=icon}
37API의 핵심기술 중에 하나인 쓰레드라는 것이 있습니다.
한개의 프로세서가 동작할때 여러개의 작업을 동시에 해야 할 경우, 쓰레드라는 것을 이용하면 멀티적인 동작을 하는 것 처럼 보이는 게 가능한 윈도우의 특성을 잘 살린 다중 작업의 한 방법이죠.
공부하면서 이 부분 참 관심있게 봤었는데, 쓰레드를 이용해서 화면만 지속적으로 출력하는 쓰레드를 만든다든지, 전투에서는 유저와 몹의 이동및 공격 데이터를 관리하는 쓰레드를 만든다든지..
근데 IT EXPART 3D 게임 프로그래밍 이란 책을 보면, 랜더링 쓰레드를 사용할때 동기화를 잘못했을 경우 치명적인 오류의 위험이 있다던데, 실제 게임을 만들때도 쓰레드를 어느 부분까지 응용하는지, 그리고 어디까지 연구가 되어있는지도 궁금해 지더군요.
혹시 아시는 분 있나요???
한개의 프로세서가 동작할때 여러개의 작업을 동시에 해야 할 경우, 쓰레드라는 것을 이용하면 멀티적인 동작을 하는 것 처럼 보이는 게 가능한 윈도우의 특성을 잘 살린 다중 작업의 한 방법이죠.
공부하면서 이 부분 참 관심있게 봤었는데, 쓰레드를 이용해서 화면만 지속적으로 출력하는 쓰레드를 만든다든지, 전투에서는 유저와 몹의 이동및 공격 데이터를 관리하는 쓰레드를 만든다든지..
근데 IT EXPART 3D 게임 프로그래밍 이란 책을 보면, 랜더링 쓰레드를 사용할때 동기화를 잘못했을 경우 치명적인 오류의 위험이 있다던데, 실제 게임을 만들때도 쓰레드를 어느 부분까지 응용하는지, 그리고 어디까지 연구가 되어있는지도 궁금해 지더군요.
혹시 아시는 분 있나요???
2005.07.03 01:02:21 (*.99.139.82)
Excelsis 쓰레드는 기본적으로 동시접근의 위험성을 가집니다. 크리티컬 섹션을 잘 사용해주어야 하는 어려움이...
서버 구현시에는 데이터 송수신용 쓰레드가 있어야 하고,
게임로직 쓰레드가 있을수도 있고, 접속받아들이는 쓰레드가 있을수도 있습니다.
(게임의 내용이 패시브에 가까울때는 게임로직 쓰레드가 패킷수신시에만 돌아가도 되고요, 접속받는 쓰레드는 걍 메인코드에서 루프로 돌리고 있어도 될거같던데... )
클라이언트의 경우 렌더링 쓰레드, 이동 쓰레드, 충돌 쓰레드 이런식으로 나눈다는 사람도 있는거같았는데
주로 원 쓰레드로 처리하는게 좋다고 합니다. 그러나 네트워크가 들어가면 어쨌든 송수신용 쓰레드도 돌아가야죠.
그리고 음악 처리 부분에서 버퍼링 처리에서 쓰레드를 쓰기도 합니다.
사실 쓰레드는 두세개정도면 꽤 괜찮은 성능을 내는데, 많아지면 많아질수록 크리티컬 섹션 처리가 어려워지고
오히려 컨텍스트 스위칭 시간 때문에 오히려 느려진다고 합니다. 구현 의도에 맞춰 꼭 쓸데가 아니라면 적게 쓰는게 좋지요.
서버 구현시에는 데이터 송수신용 쓰레드가 있어야 하고,
게임로직 쓰레드가 있을수도 있고, 접속받아들이는 쓰레드가 있을수도 있습니다.
(게임의 내용이 패시브에 가까울때는 게임로직 쓰레드가 패킷수신시에만 돌아가도 되고요, 접속받는 쓰레드는 걍 메인코드에서 루프로 돌리고 있어도 될거같던데... )
클라이언트의 경우 렌더링 쓰레드, 이동 쓰레드, 충돌 쓰레드 이런식으로 나눈다는 사람도 있는거같았는데
주로 원 쓰레드로 처리하는게 좋다고 합니다. 그러나 네트워크가 들어가면 어쨌든 송수신용 쓰레드도 돌아가야죠.
그리고 음악 처리 부분에서 버퍼링 처리에서 쓰레드를 쓰기도 합니다.
사실 쓰레드는 두세개정도면 꽤 괜찮은 성능을 내는데, 많아지면 많아질수록 크리티컬 섹션 처리가 어려워지고
오히려 컨텍스트 스위칭 시간 때문에 오히려 느려진다고 합니다. 구현 의도에 맞춰 꼭 쓸데가 아니라면 적게 쓰는게 좋지요.
2005.07.03 01:34:04 (*.141.40.88)
클라이언트에서 쓰래드는 로딩 부분에서 제일 큰 몫을 차지합니다..
유저에게 기다림의 시간을 최대한 줄여주기 위해서죠.
윗분이 말씀하신 음악 처리부분도 마찬가지구요..
그리구 쓰래드도 디버깅 됩니다..
유저에게 기다림의 시간을 최대한 줄여주기 위해서죠.
윗분이 말씀하신 음악 처리부분도 마찬가지구요..
그리구 쓰래드도 디버깅 됩니다..
2005.07.03 03:16:23 (*.39.128.201)
![[레벨:4]](http://old.lameproof.com/modules/point/icons/default/4.gif "포인트:1447point (0%), 레벨:4/30"){kind=icon}
리피 크리티컬 섹션은 필수적으로 걸어야 하고..
걸면 그것에 의한 코스트 때문에 느려집니다..
(비용이 매우 크죠)
그렇다고 안걸면 아이템 복사라던가..등등의 큰 문제가 발생하지요.
때와 상황에 따라..CPU수에 따라 스레드의 최적화는 당연히 달라지겠지요.
듀얼코어가 보급화 되면 현재와는 다르게 프로그래밍이 진행될꺼 같군요..
아직은 싱글코어 싱글CPU에서는 2개정도의 스레드가 최적화라고 봅니다 ^^
걸면 그것에 의한 코스트 때문에 느려집니다..
(비용이 매우 크죠)
그렇다고 안걸면 아이템 복사라던가..등등의 큰 문제가 발생하지요.
때와 상황에 따라..CPU수에 따라 스레드의 최적화는 당연히 달라지겠지요.
듀얼코어가 보급화 되면 현재와는 다르게 프로그래밍이 진행될꺼 같군요..
아직은 싱글코어 싱글CPU에서는 2개정도의 스레드가 최적화라고 봅니다 ^^
2005.07.04 08:20:06 (*.237.153.171)
1ststory 최근 빨라진 CPU와 듀얼코어가 등장하면 쓰레드라는 부분도 어느정도 활성화 시킬수 있지 않을까요? 이론상 기존보다 2배의 처리속도를 보일텐데 말이죠?
2005.07.04 11:32:14 (*.107.113.162)
![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:3087point (84%), 레벨:5/30"){kind=icon}
안군 쓰레드는... 상호간에 공유 자원이 적은 경우에는 상당히 좋습니다. 하지만, 공유 자원이 많아질수록 문제가 심각해지지요.
깊이 들어가면 스레드도 결국은 시간을 나눠서 써먹는거지만, 직관적으로는... 몇가지 작업이 동시 진행하는거거든요.
근데, 만약 A 라는 자원을 1번 스레드가 읽고 있는데, 2번 스레드가 메모리 해제를 해버렸다... (ㅡ,.ㅡ) 라던지...
이런 일들이 생겼을때의 처리를 일일히 해줘야 한다는게 (동기화.. 그러니까 락 처리죠) 스레드의 가장 큰 단점입니다.
게다가, 이름만으로도 무시무시한 "데드락"때문에 스레드 쓰기는 더 어려워집니다.
동기화를 빡세게 한다고, 자원들마다 락을 걸게 되다보면..
1번 스레드는 A를 락 걸고 B를 기다리고, 2번 스레드는 B를 락 걸고 A를 기다린다... 는 일이 벌어지고...
두 스레드는 영원히(강제로 풀어줄 수도 없는...) 대기상태가 되는거죠.. ㅡㅡ;;;
뭐... 네트워크 프로그래밍을 하다 보면 어쩔 수 없이 수없이 많은 스레드를 생성하게 됩니다만;;;
깊이 들어가면 스레드도 결국은 시간을 나눠서 써먹는거지만, 직관적으로는... 몇가지 작업이 동시 진행하는거거든요.
근데, 만약 A 라는 자원을 1번 스레드가 읽고 있는데, 2번 스레드가 메모리 해제를 해버렸다... (ㅡ,.ㅡ) 라던지...
이런 일들이 생겼을때의 처리를 일일히 해줘야 한다는게 (동기화.. 그러니까 락 처리죠) 스레드의 가장 큰 단점입니다.
게다가, 이름만으로도 무시무시한 "데드락"때문에 스레드 쓰기는 더 어려워집니다.
동기화를 빡세게 한다고, 자원들마다 락을 걸게 되다보면..
1번 스레드는 A를 락 걸고 B를 기다리고, 2번 스레드는 B를 락 걸고 A를 기다린다... 는 일이 벌어지고...
두 스레드는 영원히(강제로 풀어줄 수도 없는...) 대기상태가 되는거죠.. ㅡㅡ;;;
뭐... 네트워크 프로그래밍을 하다 보면 어쩔 수 없이 수없이 많은 스레드를 생성하게 됩니다만;;;