인프런 커뮤니티 질문&답변

JobSerializer라는 순차적으로 실행되는 Job 시스템 내부에서
FindPlayer를 호출하는 것은 아무런 문제가 없으니,
Job 내부에서만 사용하도록 정책을 정하는게 제일 단순합니다.

그게 아니라면 원래 하던 방식처럼 FindPlayer 내부에서 lock을 걸고,
앞으로 _players를 사용할 땐 꼭 lock을 걸어도 되지만 그러면 좀 헷갈릴 수가 있죠.

마지막으로는 말씀하신 것처럼 우리가 원래 하려던 행위를
대신 해주는 일감을 (Callback 함수를 포함해서..) JobQueue에 만들어서 넣어주고
나중에 이 콜백이 호출되게 유도해도 되긴 하지만,
보통 외부에서 꺼내서 사용해야 하는 경우는 당장 필요한 경우가 많아
이 또한 조금 까다로운 경우가 많습니다.

그나저나 질문하신걸 보니 일단 Job에 대한 장단점 이해를 잘하신 것 같네요!
참고로 말씀드리면 테라의 경우 모든 GameObject들이 자신의 JobQueue를 들고
모든 일감들이 해당 JobQueue를 이용해서 진행 되었습니다.
그런데 가끔 게임 사양 중에서 상대방의 JobQueue를 거치지 않고 정보를 추출할 필요가 생기는데
(ex. 상대방이 특정 디버프를 들고 있으면 나가는 스킬이 있다면?)
이럴 때는 아주 잠시 lock을 걸어주거나,
아니면 애당초 멀티쓰레드 환경에서도 동시 접근/수정해도 안전한 자료구조를 사용했습니다.
(ex. 디버프를 동적배열 vector로 관리하지 않고, 고정 크기의 배열로 관리.
이러면 설령 지금 접근하는 디버프 데이터가 100% '현재' 데이터라는 것은 보장받지 못하지만,
최소한 다른 쓰레드가 접근해서 수정하더라도 크래시가 나진 않겠죠)

말씀해주신 것처럼 외부에서 꺼내서 당장 사용해야하는 경우에는 Func도 해답은 아니겠네요..ㅠ

Part 4에서 한번 듣고 또 한번 들으니깐 그나마 좀 Job 시스템이 이해가 되는 것 같습니다

그리고 마지막에 말씀해주신 팁은 정말 소름돋네요..;;

먼가 다단계 구조처럼 JobQueue를 사용하는 것 같은 느낌적인 느낌입니다.

(몬스터나 플레이어, 사물이 들고 있는 JobQueue들 관리하는 JobQueue가 또 있을 것 같은?)

또한 멀티쓰레드 환경에서도 안전한 자료구조가 있을거란 생각은 1도 못했는데.. 정말 소름이지만 한편으로는 이런 꿀팁을 또 알려주셔서 감사할 따름입니다.

언제 어디로 이직을 하게 될지는 모르겠지만 루키스님께 항상 감사한 마음을 품을 것 같아요.

좋은 강의 공유해주셔서 진심으로 감사드립니다.