2010-06-28 3 views
2

현재 .NET에서 메시지 기반 멀티 스레딩을 위해 Retlang을 사용하고 있습니다.이 라이브러리는 훌륭한 라이브러리입니다. 나는 명시 적 잠금을 가지고 있지 않으며 모든 스레드는 자체 비즈니스를 수행하고 응용 프로그램의 일부를 관리하며 메시지를 통해 다른 스레드와 통신합니다.짧고 드문 동작을위한 메시지 기반 다중 스레드 또는 스레드 풀?

이제 독자적인 게시자/구독자 스레드를 가질 수있는 응용 프로그램 기능을 구현해야합니다. 유일한 문제는이 스레드가 실제로 거의 작동하지 않는다는 것입니다. 10 분마다 게시자로부터 메시지를받을 것으로 예상됩니다. 메시지가 수신되면 몇 가지 작업을 수행하지만 수백 밀리 초 이상 걸리지는 않습니다.

그래서 나는 99.9 %의 시간 동안 잠자는 스레드가 실제로 좋은 선택인지 궁금해하기 시작했습니다. 이러한 종류의 작업을위한 스레드 풀이 있지만 메시지를받을 스레드를 제어 할 수 없으므로 오류가 발생하기 쉬운 잠금 장치를 사용해야합니다.

내 질문은 : 스레드를 유휴 상태로 두는 것이 자원으로 현명한 문제인지, 대다수의 시간을 기다리고 있습니까? 좋은 메시지 기반 아키텍처를 사용한 후에 공유 멀티 스레딩을 사용하면 시간이 거슬러 올라간 것처럼 느껴질뿐만 아니라 잠금 기능이있는 응용 프로그램의 유일한 부분이 될 것입니다. 그러나 나는 계속해서 "내가 여기서 뭔가 잘못하고있는 걸까?"하고 계속 궁금해합니다. 이 스레드로.

: 감사합니다. 모든 답변을 읽은 후에 다른 스레드가별로 문제가되지 않는다고 결정했습니다. 내 응용 프로그램은 메시지 기반 멀티 스레딩만으로 일관성을 유지할 것이며 성능 문제가 실제로 발생하더라도 (그렇다고해서는 안됨) 추가 조사를하겠습니다.

답변

3

나는 것 실제로 대부분의 시간을 자고 스레드에 대한 ThreadPool이를 사용하여 가난한 디자인 선택이라고 주장 - 단일 스레드 수면 (또는, 더 나은, 이벤트에 대기)를 갖는

약간의 오버 헤드가 귀하의 신청서에 전용 스레드를 사용하는 데있어서 가장 큰 단점은 스레드가 자체 스택을 할당해야하므로 스레드 풀과 비교하여 약간의 추가 메모리를 사용한다는 것입니다.

+0

나는 약간의 추가 메모리에 대해 걱정하지 않는다. 메모리는 이러한 종류의 애플리케이션에 문제가되지 않는다. 주로 염려했던 응용 프로그램에서 다른 스레드의 잠재적 인 영향이었습니다. –

2

Task을 사용하는 것이 이상적인 소리입니다. 그들은 기본적으로 스레드 풀을 밑에서 사용하지만 더 진화 된 API를 가지고 있습니다.

+0

(ThreadPool에서 스레드 기아를 방지하기 위해) LongRunning 힌트로 생성 된 태스크에 대한 좋은 후보가되는 점을 제외하고는 예외입니다. 그러나이를 수행하면 전용 스케줄러를 사용하는 전용 스레드를 생성하게되므로 Task는 잠재적으로보다 깨끗한 API 이외의 다른 이점을 제공하지 않습니다. –

+0

음, 아니요. 나는 할 일마다 '과제'를 만드는 것을 의미했습니다. 그래서 각각의'Task'는 매우 수명이 짧습니다. –

0

저는 이것이 근본적으로 최적화의 문제라고 생각합니다. 응용 프로그램에 성능 문제 (특히 메모리 문제)가 있습니까? 그렇지 않으면 스레드를 유휴 상태로두고 코드를보다 깨끗하게 유지하십시오. 진짜 이유가 있으면 다른 옵션을 탐색하십시오.

1

Retelang의 PoolFiber을 사용할 수 없습니까? ThreadFiber과 같은 전용 스레드가 아니라 .Net 스레드 풀을 통해 지원됩니다. 즉, 유휴 상태의 스레드를 유지하지 않고 응용 프로그램 전체에서 사용중인 동일한 Retlang 의미를 계속 사용할 수 있습니다.

+0

나는 이미 그것에 대해 알고 있었고 그것을 사용할 계획이었다. 그러나 임의의 스레드 풀 스레드에서 메시지를 생성하므로 작업이 기존 개체와 동기화되고이 스레드의 작업간에 공유되지만 다른 스레드와는 공유되지 않아야합니다. –

+0

문제가 있습니다. 이러한 유형의 동기화는 방지하려는 것입니다. 그러나 이러한 기존 객체에 대한 액세스를 다른 파이버를 통해 사용자에게 숨겨서는 안됩니까? 나는. 이 물체들을 업데이트하는 광섬유와 통신하기 위해 메시지를 다시 사용해서는 안됩니까? –

+0

이것이 내 문제의 핵심입니다. 문제가있는 스레드는 응용 프로그램의 독립적 인 부분입니다. 물론 다른 섬유와 통신하지만 고유 한 개체가 있으며이 섬유/스레드에서만 사용되며 바깥에 노출되지는 않습니다. –

0

나는이 메시지를 잘 받기위한 전용 스레드가 있어야한다고 말합니다. 나는 이것이 선호되는 방법이라고 말할 때까지 갈 수도 있습니다. 당신이 방금 쓸데없는 것 또는 그와 같은 것을 만들지 않는 것은 아닙니다. 우리는 여기에 하나의 여분의 스레드에 대해 이야기하고 그것은 많은 자원 (어쩌면 작은 스택 공간)을 소비하지 않습니다. 공유 상태의 추가 동기화에 대해 걱정할 필요가 없다는 장점은 (물론 메시지 전달과는 별도로) 제 생각에는 불리한 점이 있습니다.

0

F # 사용을 고려해야합니다. 스레드를 굽히지 않고 논리적으로 단일 스레드 에이전트를 프로그래밍하는 데 좋습니다 (예 :에이전트는 ThreadPool에 대해 호핑 할 수 있지만 메시지에 순차적으로 응답하고 사서함에 도착하는 메시지는 해당 메시지를 깨우고 ThreadPool 작업을 예약합니다. PoolFiber 각 작업은 별도의 스레드 풀 실행할 수 있지만

http://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

+0

전체 응용 프로그램은 이미 C#으로되어 있으며 F #을 배우고 싶어하지만 현재 배울 시간이 없으며 다른 언어로 응용 프로그램의 아주 작은 부분을 구현하는 것이 그만한 가치가 있다고 생각하지 않습니다. . –

1

특정 PoolFiber위한 작업은 한번에 병렬로 순차적으로 단지 하나의 스레드 풀을 실행한다.

PoolFiber는 찾고있는 것을 처리해야합니다.

+0

고맙습니다. 전 전혀 깨닫지 못했습니다. 너 Retlang의 작가 중 한 명인 Graham Nash 야? 훌륭한 라이브러리를 가져 주셔서 감사합니다! (내가했던 것처럼 Erlang이나 Scala에 대한 경험이 없을 때 문서가 부족하다는 것을 알았지 만) –

+0

예, 저입니다. Mike Rettig는 대부분의 작업을 수행했지만, 그냥 유지 관리합니다. Retlang 1.0.1이 출시되었으므로 문서를 개선하기 위해 노력할 것입니다. 특히 일을해야하는 분야는 무엇입니까? – gnash