leafbird/devnote

들어가며

지난 글(링크)에서는 Actor 패턴을 MMO 서버에 적용할 때의 두 가지 접근 방식 — Zone 단위의 Coarse-grained 방식과 Object 단위의 Fine-grained 방식 — 을 비교해 보았습니다.

이제 드디어 실제 코드를 살펴볼 차례입니다. 이번 글에서는 현재 프로젝트에서 사용 중인 경량 Actor 구현체의 핵심 구조를 소개합니다. 주로 스레드가 어떻게 운용되는지, 그리고 c#의 비동기 메서드(async/await)로 인해 끊겼다 이어지는 스레드 흐름을 어떻게 다루는지에 대해 적어보겠습니다. 다음 주제들을 하나씩 다뤄볼게요.

• Symmetric 스레드 모델: 역할이 고정된 스레드가 아닌, 모든 스레드가 모든 일을 처리하는 방식
• 메시지 큐와 스케줄링: JobDispatcher를 중심으로 한 작업 분배
• Starvation 방지: readyQueue를 통한 공정한 처리
• 동기/비동기 메시지 분리: await 키워드와 함께 자연스럽게 동작하는 구조

들어가며

지난 글(링크)에서는 POSA 2의 동시성 패턴들 — Reactor, Proactor, Actor — 을 간단하게 소개하고 살펴보았습니다. 이론적 배경을 이해했으니, 이제 실전으로 넘어갈 차례입니다.

근데 이제.. 실제 게임 만들 때 Actor 모델을 어떻게 적용한다는 건가?

이 질문에 정해진 답은 없습니다. 하지만 Actor의 적용 범위에 따라 실제 프로그래머가 코딩하는 환경이나 완성된 시스템의 동작 특성은 제법 큰 차이가 발생합니다. 이번 글에서는 MMO 게임속 상황을 예시로, 두 가지 대조적인 접근 방식을 살펴보겠습니다.

들어가며

동시성 프로그래밍은 현대 소프트웨어 개발에서 피할 수 없는 주제입니다. 멀티코어 프로세서가 보편화되고, 분산 시스템이 일상이 된 지금, 효율적이고 안전한 동시성 처리는 더 이상 선택이 아닌 필수가 되었습니다.

이 글에서는 현재 프로젝트에서 직접 작성해 사용하고 있는 C# Actor 구현체를 소개하기에 앞서, 먼저 Actor 패턴의 이론적 배경을 살펴보고자 합니다. 특히 POSA 2에서 소개하는 동시성 패턴들을 중심으로, Actor 패턴이 어떤 맥락에서 등장했는지 이해해 보겠습니다.

올 해에 가장 잘 했던 기술적 선택을 꼽으라고 한다면
연초에 서비스 환경을 리눅스로 전환하겠다고 결정한 점이다.

아니, 정말로요. 빈 말이 아니고요.

만약에 요즘에 누군가와 사교적인 말하기를 하다가 취미가 무엇이냐는 질문을 받는다면,

요즘 터미널 꾸미는 것에 빠져있어요.

라고 대답할 것 같아요.

회사에서 빌드머신으로 사용중인 맥미니 장비들은 주기적으로 몇가지 관리가 필요하다.

최근에 유니티6로 엔진 업데이트한 이후 빌드머신에 갖가지 이슈들이 생기면서 디스크 용량 체크를 해보던 중이었다.

이거 코드 작업 조금만 하면 만들 수 있겠다는 생각이 들었고, 미루면 아마 영영 실천으로 옮기지 않게 될 것 같아 생각난 김에 바로 만들었다.

매번 터미널을 열 때마다 2 ~ 3초가 걸리는 것은 부담스럽다.

방법을 찾아야 한다.

C#에서 메서드를 정의할 때 in 키워드를 사용하면 call by value 가 아닌 call by reference로 동작하게 만들어줍니다. 그래서 주로 구조체(value type)를 복사 없이 참조로 넘길 때 유용하지요.

참조 타입의 매개변수에 in 키워드를 쓰는 건 어떤 효과가 있을까요? generic parameter를 정의할 때도 in 키워드가 붙는 경우도 있던데 어떤 의미일까요?
이참에 한 번 정리해 보겠습니다.

23년 9월부터 24년 5월까지, 8개월 정도 열심히 커밋을 남겼습니다.
그러고는 한참 손을 놓고 있었는데, 다시 한 번 시작해보려고 합니다.

그리고 이번 7.2.0 릴리즈에 제가 보낸 수정사항도 반영 되었습니다