작성
·
176
0
전에 드렸던 질문의 연장이지만..
한 공간에 많은 유저가 몰려있어 각자의 위치동기화를 위해 주변 플레이어들에게 Broadcast 하는 상황이라고 가정할때
강의에서 말씀하신 JobQueue 구조로 간다고 해도
연속된 위치동기화를 위해 Broadcast Job 을 계속해서 수행한다고 하면
사실상 Broadcast 내의에서 Session을 접근할때의 Lock 때문에 기다려야 하는 현상은 동일한것 아닌가 궁금합니다.
만약 제가 JobQueue 에 대해 놓친부분이 있다면 리마인드 해주시면 너무너무 감사드리겠습니다 !!!
답변 1
1
Broadcast를 위해 어느 정도 lock은 잡는 것은 필요하지만
Job에 대한 얘기는 그런 부분이 핵심이 아닙니다.
이해가 안 가신다면 그냥 단순하게 Job을 만들지 않고 어떻게 구현할지를 역으로 생각해보면 됩니다.
어떤 플레이어가 광역으로 스킬을 뿌리는 C_Skill 패킷을 서버에 요청했다 가정해봅시다.
Job 방식이 있다면, 이를 하나의 일감으로 만들어서 JobQueue에 바로 밀어넣고
JobQueue에 들어간 일감 들어간 순서대로 순차적으로 실행되겠죠. (번호표처럼)
Job이 없다면, C_Skill_Handler 쪽에서 플레이어가 있는 공간에 접근한 다음
lock을 잡은 상태에서 스킬 로직을 쭉 실행해야 합니다.
스킬 로직이 1초 걸리는 어마무시하게 힘든 연산 작업이라면,
나머지 쓰레드들은 1초 동안 대기를 하면서 lock이 풀릴때까지 기다려야겠죠.
결국 멀티쓰레드임에도 병목 현상이 심해지기 때문에
CPU를 효율적으로 활용을 할 수가 없게 되는 것입니다.
저도 처음에 회사 코드를 보고 이해하는데 오래 걸린 부분이니
찬찬히 고민을 해보시기 바랍니다.
결국 멀티쓰레드의 어떤 병목현상을 해결하기 위함이 아니라.
Job 이라는 단위로 일감들을 관리할수 있는 구조를 갖추는게 목적이라고 이해할수 있는것인가요 ?