1

strFilePath 배열 (각 파일에 약 1 백만 개의 레코드가있는 거의 1000 개의 파일)에 다양한 CSV 파일의 위치가 있습니다. 파일을 읽고 모든 데이터를 단일 데이터 테이블로 병합하는 데 많은 시간이 필요합니다. 그래서 병렬 처리를 진행하기로 결정했습니다.루프 외부 업데이트

현재 코드

DataTable dtMerge=new DataTable(); 
for(int i=0;i<strFilePath.Count;i++) 
{ 
    Parallel.For(0, 3,m => 
    { 
     clsNewClass objCls=new clsNewClass(); 
     DataTable dt=objCls.ReadCSV(strFilePath[m+i]); 
    }); 
    m+=3; 
} 

질문은, 어떻게 글로벌 데이터 테이블 dtMerge에 데이터 테이블 dt의 모든 데이터를 병합 할 수 있습니다 또는 전역 변수 dtMerge 모든 결과를 포함 할 수 있습니다?

예상 된 코드는 잠금을 사용하지 않고 진행 내부 스레드를 병합 할 수 있도록 스레드 마지막으로 당신에게 지역의 초기화를 제공하고

DataTable dtMerge=new DataTable(); 
for(int i=0;i<strFilePath.Count;i++) 
{ 
    Parallel.For(0, 3,m => 
    { 
     clsNewClass objCls=new clsNewClass(); 
     // Is it possible like the below? 
     dtMerge = objCls.ReadCSV(strFilePath[m+i]); 
    }); 
    m+=3; 
} 
+0

당신은이 꽤 많은 오류를 사용 둥지 이유가 없었다있어 기존 코드에서. 'm'은'm + = 3'에서 선언되지 않고 처음으로 저에게 뛰어납니다. 실제로 당신은'Parallel.ForEach (strFilePath, filepath => {...})' –

+0

을 수행하는 것이 훨씬 낫습니다. 어떻게하면 병합 할 수 있을까요? Parallel.Foreach 안에 잠금 (객체)을 사용하지 않고 어떤 방법이 있습니까? @Scott Chamberlain –

답변

1

Parallel.For (또는 ForEach)의 오버로드를 사용하려면. 그러면 merge 스레드 내부의 스레드 테이블이 스레드 안전을 위해 잠금을 사용하여 외부 테이블에있는 finally 블록에있을 수 있습니다.

DataTable dtMerge = new DataTable(); 

Parallel.ForEach(strFilePath, 
    () => new DataTable(), 
    (filePath, loopState, local) => 
    { 
     clsNewClass objCls=new clsNewClass(); 
     // Is it possible like the below? 
     var dt = objCls.ReadCSV(filePath); 
     local.Merge(dt, true, MissingSchemaAction.Add); 
     return local; 
    }, 
    (local) => 
    { 
     lock(dtMerge) 
     { 
      dtMerge.Merge(local, true, MissingSchemaAction.Add); 
     } 
    }); 

또한 루프에 대한 외부 제거 및 병렬 foreach는 귀하의 내부 루프를 대체 그런 당신의 루프, 단지 ForEach

+0

나는 의심이있다. 이 잠금은 실제로 ** Parallel.ForEach **의 성능을 반영합니까? 사실 ** 잠금 **은 한 번에 하나의 개체 만 액세스 할 수 있도록합니다. 권리??? –

+0

잠금은 작업자 스레드가 처리 될 때만 발생하므로 매우 드물게 발생합니다. 'local.Merge'는 많은 일을하게 될 것이고 자물쇠를 가지고 있지 않습니다 (당신이 합병하는 테이블이 쓰레드 로컬 객체이기 때문에 필요하지 않습니다) –

+0

당신의 소중한 시간과 대답을 위해 고맙습니다 :) @ 스콧 체임벌린 –