Page History

Versions Compared

...

Dispatcher는 성능과 관련한 액터로, 멀티스레드개념을 어느정도 단순화하고 옵션화를 했다고 보시면될듯합니다.

이와 관련하여 위 그래프는 아주 중요한 의미를 내포하고 있습니다.

고성능처리를 위해서 개발 복잡도가 증가하고 (심각하게는 고성능처리에 대해 아무것도 할수 없음)

요구사항 (최대동접) 증가로인해, 필요한 자원이 계속 증가한다면 그것은 파멸적 시나리오로 연결될것입니다.

대부분 팀내에 실질적인 문제는 그러한 문제를 인지못하거나, 측정할 능력이 없다는데 있으며

분산 개발 환경에서 분산환경에서 해결 키 포인트가 멀티스레드 작성이라고 생각한다면 다행입니다. 하지만 그것은 답이아닙니다.생각하고, 시도 했다면 다행입니다.

심각한 문제는 그것이 고급 개발자가 해야되는 덕목으로 분산환경및 복잡한 연산처리에서도 이것이 해결을위한 키포인트로 정의 내리는 굳은 믿음에 있으며

실제 그러한 믿음을 가진사람은 멀티스레드에서 생기는 많은 문제를 운영중 처리를 하지 못했거나, 경험이 없다란 것입니다.

오히려 운영에서 멀티스레드 작성을 통해 오랫동안 문제사항을 겪고 노하우가 쌓인 개발자는 현재 대부분 비동기처리 개발언어에서 지원하는

async 라는 지원 키워드를 감사하게 쓰고있고, 돌아가지 않습니다.

과거 10년전을 생각하면 메모리를 직접관리하느게 가비지 컬렉트보다 뛰어나다라 생각했을지 모릅니다.

현재는 가비지 컬렉트를 설계한사람이 어떠한 한팀에서 메모리를 직접 컨트롤하는것보다 더 좋은 메카니즘을 제공하는 가능성이 크며

JAVA/NET에서 이루어지는 가비지 컬렉트에대해 큰 문제가 있다라고 생각하지 않습니다.

스레드도작성도 어떠한 특수분야가 아닌이상(실제로 병령 처리를 통해 단일기기에서 극한의 결과물을 산출하는 개발자가 있을지 모르겠습니다)

이것은 개발복잡도 증가요인으로 해당이 되는 사항입니다.

이미 동시성 처리를 위해 멀티스레드를 직접 작성하지않는 여러가지 모델들이 등장했으며

액터모델은 그중에 하나일뿐입니다.