2012-05-26 1 views
1

나는 현재 Pro을 읽었습니다. NET 4.0 병렬 프로그래밍 C#, 그러나 각 장 끝에 연습이 없습니다. 비록 내가 그 개념을 이해하지만, 나는 여전히 실제적인 실천이 부족하다고 느낀다. 내가 배운 것을 강화하기 위해 몇 가지 실제적인 문제가 필요하다. 인터넷을 통해 검색했지만 주로 자습서 ...
TPL에서만 타겟팅하는 문제 세트가 있습니까? 나는이 라이브러리가 여러면에서 매혹적이라는 것을 알았고 나는 단지 그것을 에이스로 만들고 싶다. 그래서 누군가가 내 지식을 연습 할 수 있도록 TPL 영역에서 나에게 몇 가지 문제를 나눌 수 있는지 궁금합니다. 발생한 모든 문제 또는 참조는 크게 감사하겠습니다. 난 그냥 문제가 필요해, 내가 해결책을 직접 찾을거야. 미리 감사드립니다.TPL 라이브러리가 필요한 전형적인 문제는 무엇입니까?

답변

2

TPL은 모두 내 생각에 확장성에 관한 것입니다. 이런 식으로 생각하면 코드에서 활용하는 방법을 찾을 수 있습니다. 병렬로 처리하지 않으면 순차적으로 처리됩니다. 아주 작은 동작을하는 작은 응용 프로그램에서는 순차 처리가 좋습니다. 그러나 특정 프로세스에 대한 수천 건의 요청이있을 때 - 여기가 TPL이 들어오는 곳입니다.

요청 목록을 처리한다고 가정 해보십시오. 요청에 웹 사이트에 대한 URL이 있습니다. 이 과정은 HTML 컨텐트를 다운로드하고 페이지에서 특정 데이터를 가져 와서 데이터베이스에 저장하는 것입니다. 일반적으로 이것은 순차적으로 수행되어야합니다. 이제 10 명이 동시에이 요청을 수행한다고 상상해보십시오. 마지막으로 제출 버튼을 누른 사람은 다른 모든 사람이 처리를 마칠 때까지 기다려야합니다. 이것은 매우 오랜 시간이 걸릴 수 있으며 무기한 증가합니다.

시각적 표현은 :

TPL와
[Request01] - Finished 
[Request02] - Started 
[Request03] - Waiting 
[Request04] - Waiting 
[Request05] - Waiting 
[Request06] - Waiting 
[Request07] - Waiting 
[Request08] - Waiting 
[Request09] - Waiting 
[Request10] - Waiting 

- 당신은 동시 컬렉션에서 이러한 요청 (TPL 컬렉션)를 저장 및 병렬에서 컬렉션을 반복 할 수 있습니다. TPL은 스레드에서 이러한 요청을 분할하고 동시에 실행하며 프로세서의 각 코어에서이를 수행합니다.

듀얼 코어 프로세서가 2 개인 서버가 있다고 가정 해보십시오. 과정은 다음과 같이 보일 것입니다 :

CPU1 Core1 
    [Request01] - Finished 
    [Request02] - Started 
    [Request03] - Started 

CPU1 Core2 
    [Request04] - Finished 
    [Request05] - Started 
    [Request06] - Started 

CPU2 Core1 
    [Request07] - Finished 
    [Request08] - Started 
    [Request09] - Started 

CPU2 Core2 
    [Request10] - Finished 

당신이 볼 수 있듯이 - 이것은 더 많은 생산과 더 적은 대기 시간을 허용합니다. TPL에 대한 좋은 점은 - 사운드 애플리케이션을 개발할 수 있다면 소프트웨어의 확장 성이 하드웨어로 떨어지게된다는 것입니다. 이 서비스에 관객이 많을수록 더 많은 서버를 던질 수 있습니다. IT 세계에서 이것은 더 받아 들여질 수 있습니다. 누구나 하드웨어를 확장 할 의향이 있습니다. 아무도 소프트웨어를 업데이트하려고하지 않습니다.

올바른 방향으로 안내해주세요.

1

TPL로만 해결할 수있는 특수한 문제가 있다고 생각하지 않습니다.

TPL의 목적은 응용 프로그램에 병렬 처리 및 동시성을 추가하는 과정을 단순화하여 개발자의 생산성을하는 것입니다. TPL은 동시성의 정도를 동적으로 조정하여 사용 가능한 모든 프로세서를 가장 효율적으로 사용합니다. TPL을 사용하여 프로그램이이 MSDN에서 TPL의 설명/목적이다

달성하기 위해 설계 작업에 집중하는 동안 당신은 당신의 코드의 성능을 극대화 할 수 있으며, 나는 그것을 멋지게 그것을 요약 한 생각;
tpl에 대해 묻는 질문은 일반적으로 멀티 스레딩에 대해 질문 할 수 있으며 멀티 스레딩이 최상의 솔루션 성능인지 여부를 항상 쉽게 알 수 있습니다 (아주 명백한 경우는 제외하고 코드가 독립적 인 데이터 소스에 액세스해야합니다. 멀티 스레딩을 결정할 때 이벤트가 문제를 해결하는 가장 좋은 방법이며 사용하는 스레드 수와 스레드 간 작업을 분할하는 방법을 자동으로 지정할 수 없습니다.
일부 웹 서비스를 통해 X 전자 메일을 보내야하는 응용 프로그램이 있다고 가정 해 보겠습니다. 모든 X를 하나의 큰 루프로 보내시겠습니까? 그들을 별도의 N 개의 스레드로 나누고 각 스레드에서 X/N을 보냅니 까? 그러한 질문은 때로는 시험 및 성과 모니터링 모니터링으로 만 대답 할 수 있습니다. TPL 라이브러리는 이러한 문제를 해결하기 위해 다음과 같은 목표를 제시합니다. 모든 계산을 수행 할 것을 기대하는 대신 (각 실행마다 동일한 결과가 나타남) tpl은 필요한 병렬 처리 수준을 동적으로 계산하여 이론적으로는 각 경우에 대해 최상의 성능을 제공하는 것을 목표로합니다.

1

저는 TPL과 여러 번 일했으며 매우 도움이되었습니다. 내 경험에 비추어 볼 때 다음과 같은 문제가있었습니다.

  1. 온라인 지불 시스템을 연구하고있었습니다. 이론적으로 초당 수 백에서 수천 건의 지불이있을 수 있습니다. 지불 할 때마다 누군가가 돈을 지불했다는 것을 서비스 제공 업체에 알리기 위해 웹 서비스를 호출해야했습니다. 서비스를 호출하는 것은 IO 작업이기 때문에 곧 사이트 풀에서 서비스를 호출하는 것이 의문이었습니다. 풀에서 곧 스레드가 부족하기 때문입니다. 그래서 저는 작업 스케줄러를 사용하기로 결정했습니다. 작업은 주기적으로 실행되고 데이터베이스에서 보류중인 지불 (트랜잭션)을 가져 오며 TPL이 빛나는 곳입니다. 수천 또는 수천 건의 서비스를 하나씩 보내면 매우 비효율적입니다. 그래서 TPL을 사용했습니다. 최적의 스레드 양을 자동으로 할당하고 적절한 서비스를 병렬로 호출합니다. 필자가 말했듯이, 웹 서비스 호출은 IO 작업이기 때문에 기계의 논리적 코어보다 많은 스레드를 할당하는 것이 좋을 것입니다 (아마도 필수 항목 일 것입니다).
  2. 또 다른 문제는 IO 작업이 발생하지 않는 많은 양의 데이터 (예 : 컬렉션의 배열로 나타낼 수 있음)를 처리해야 할 때 모든 것이 CPU에 바인딩된다는 것입니다.TPL을 사용하여 여러 CPU/코어에 걸쳐로드를 분산시킬 수 있습니다. 이 경우 CPU 코어 당 스레드가 1 개인 것이 가장 좋습니다.