1 00:00:00,000 --> 00:00:04,582 자막제작: 정재원(all2one) http://vsts2010.net http://gl3d.net 2 00:00:04,743 --> 00:00:10,249 그리고 call은 메시지를 받으면 특정 작업을 하게 하는 것이죠. 3 00:00:12,220 --> 00:00:14,220 그 다음으로 choice와 join입니다. 4 00:00:15,217 --> 00:00:23,291 WaitForMultipleObjects나 WaitForSingleObject 같은 것을 사용해 이벤트를 기다린 후 여러분이 원하는 데이터를 살펴보는 대신 5 00:00:23,602 --> 00:00:24,928 choice를 사용할 수 있습니다. 6 00:00:25,527 --> 00:00:31,681 일련의 입력을 훅킹한 후 가장 먼전 도착한 놈을 얻어서 7 00:00:32,181 --> 00:00:37,744 실제 기다리던 놈에 작업을 시작하는 것이죠. 8 00:00:38,244 --> 00:00:41,014 그 다음은 join으로, 모두를 기다리는 역할입니다. 9 00:00:41,375 --> 00:00:44,501 실제로는 여러 종류의 join이 있는데요, 10 00:00:44,803 --> 00:00:51,087 Greedy join 같은 경우 얻자마자 바로 소비해버리는 형태로 11 00:00:52,183 --> 00:00:57,899 이를 겹쳐서 여럿 사용하는 경우 문제가 될 수 있지만 상당히 빠르다는 장점이 있습니다. 12 00:00:58,061 --> 00:01:05,310 한편, 모든 것이 다 준비되기를 기다리는 join도 있습니다. 13 00:01:05,810 --> 00:01:12,119 각각의 메시지 offer를 받아들여 모든 offer가 준비되었을 때 실제 작업에 착수하는 것이죠 14 00:01:12,321 --> 00:01:21,956 물론 그 전에 실제 모든 offer가 현재도 유효한지 살피는데요, 그 사이 다른 놈이 가로챘을 수도 있기 때문이죠. 그래서 오래걸릴 수 있는데 WaitForMultipleObjects와 유사한 놈으로 보시면 되겠습니다. 15 00:01:25,040 --> 00:01:26,277 예를 살펴보죠. 16 00:01:26,777 --> 00:01:31,046 매우 간단한 파일 파서입니다. 17 00:01:31,149 --> 00:01:36,215 행별로 파일을 읽어서 18 00:01:38,306 --> 00:01:42,698 파싱합니다. 19 00:01:43,198 --> 00:01:47,779 wszLine이 현재 행으로 그를 파싱하고 있습니다. 20 00:01:47,961 --> 00:01:54,447 흥미로운 것은 이 코드가 제가 작업했던 작은 유틸리티 프로그램에서 나온 것인데, 21 00:01:54,788 --> 00:01:57,557 입출력에 1초, 연산에 3초가 걸리는 놈이었습니다. 22 00:01:57,699 --> 00:02:03,450 병렬 처리가 아니어서 보기에 많이 안타까웠습니다. 23 00:02:03,473 --> 00:02:13,230 저의 강력한 쿼드코어 머신에서 느리게 동작했기 때문이죠. 특히나 입출력 시에는 CPU가 놀겠죠. 24 00:02:16,096 --> 00:02:22,556 이를 해결하려고 Agents Library를 사용해보았습니다. 25 00:02:23,334 --> 00:02:28,351 먼저 메시지 버퍼를 하나 만들어야 합니다. 26 00:02:28,493 --> 00:02:31,436 AgentMessage를 담는 unbounded_buffer입니다. 27 00:02:31,499 --> 00:02:39,244 AgentMessage는 메시지 종류와 현재 행의 payload를 가지는 간단한 메시지 타입이 되겠습니다. 28 00:02:40,002 --> 00:02:46,423 그 다음에는 ParserAgent 변수 선언이 보이는데요, 이 놈은 다음 슬라이드에서 확인하실 수 있습니다. 29 00:02:47,122 --> 00:02:49,122 그리고는 parseAgent를 시작합니다. 30 00:02:49,821 --> 00:02:55,250 대부분의 코드가 거의 비슷한데요, 파일을 열고 파일 끝까지 돌면서 31 00:02:55,452 --> 00:03:02,345 각 행을 읽어 바로 파싱하지 않고, 새로운 AgentMessage를 만들어 unbounded_buffer로 보내고 있습니다. 32 00:03:03,342 --> 00:03:08,480 루프를 나오면 종료를 알리는 메시지를 보내고 parseAgent가 끝나기를 기다립니다. 33 00:03:13,553 --> 00:03:15,553 이것이 agent 정의입니다. 34 00:03:16,371 --> 00:03:18,371 agent를 상속하는 새로운 클래스인데요, 35 00:03:19,288 --> 00:03:22,833 내부에 unbounded_buffer에 대한 참조를 가집니다. 36 00:03:23,075 --> 00:03:25,889 이는 여기서는 안보이지만 생성자에서 초기화되고요, 37 00:03:25,991 --> 00:03:27,397 그 다음으로 Run() 메소드가 보입니다. 38 00:03:27,598 --> 00:03:31,651 에이전트를 시작하면 비동기적으로 이 메소드가 호출됩니다. 39 00:03:31,912 --> 00:03:35,181 이 메소드는 메시지 버퍼에 대해 블록킹 receive를 호출하고요, 40 00:03:36,079 --> 00:03:39,293 EXIT 메시지를 받을 때까지 41 00:03:40,131 --> 00:03:45,577 메시지를 파싱한 후 호출 측에서 할당한 메모리를 날리고 있습니다. 42 00:03:46,352 --> 00:03:51,254 EXIT 메시지를 받으면 작업을 마치고 에이전트는 종료합니다. 43 00:03:52,927 --> 00:03:54,927 아주 간단하죠. 44 00:03:55,924 --> 00:03:59,103 그리고 제 유틸리티 프로그램에서 꽤나 잘 동작했습니다. 45 00:04:04,357 --> 00:04:10,191 좀 더 자세히요? 알겠습니다. 46 00:04:11,610 --> 00:04:16,123 하이라이트된 부분과 같이 그 자리에서 파싱하기보다는 47 00:04:17,062 --> 00:04:22,219 일종의 정렬된 메시지 큐 역할을 하는 unbounded_buffer를 이용해 48 00:04:27,805 --> 00:04:29,646 그리로 메시지를 보냅니다. 49 00:04:29,915 --> 00:04:33,461 에이전트는 선언하면서 바로 시작시켰는데요, 50 00:04:33,614 --> 00:04:38,741 그의 Run() 메소드가 EXIT 메시지가 도착할 때까지 비동기로 돌게 됩니다. 51 00:04:41,252 --> 00:04:44,555 이제 에이전트가 돌고 있으므로 52 00:04:45,864 --> 00:04:52,661 while 루프에서 블록킹 receive가 수행됩니다. 53 00:04:53,161 --> 00:04:57,379 즉, 에이전트는 시작해서 메시지가 도착하기를 기다리고 있습니다. 54 00:04:57,671 --> 00:05:03,864 메시지가 도착하자마자 런타임이 대기 중이던 에이전트를 깨우면 55 00:05:04,364 --> 00:05:07,589 메시지 처리 후 다시 while 루프 첫머리의 블록킹 receive로 가게 됩니다. 56 00:05:08,528 --> 00:05:11,817 답이 되었나요? 네 57 00:05:19,538 --> 00:05:28,437 네, 파싱 작업을 더 잘게 나눌 수도 있습니다. 이미징 데모에서는 실제 그렇게 하고 있고요. 58 00:05:28,567 --> 00:05:34,942 transform 및 call도 비슷하게 동작합니다. 그래서 이 에이전트 대신 transform을 적용할 수 있습니다. 59 00:05:35,165 --> 00:05:41,151 에이전트에서처럼 한순간에 하나만 돌기 때문에 60 00:05:41,443 --> 00:05:50,650 스레드 안정성이 보장됩니다. 함수나 함수개체, 람다 등을 그 transform에 전달할 경우, 오직 한 transform 인스턴스만이 도는 것이죠. 61 00:05:51,404 --> 00:05:57,865 더 비동기적으로 파이프라인을 작성할 수도 있습니다만, 여기서는 간단히 스레드 안정성을 택한 것이죠. 62 00:06:01,001 --> 00:06:05,775 다시 이미징 데모로 돌아가, 규모가변성을 부여해봅시다. 63 00:06:09,743 --> 00:06:11,743 시나리오를 기억하시죠? 64 00:06:15,017 --> 00:06:17,017 디렉토리에서 이미지 파일들을 검색하고 65 00:06:17,517 --> 00:06:21,751 디스크에서 이미지들을 로딩한 후 이미지 필터들을 적용합니다. 66 00:06:23,014 --> 00:06:25,014 병렬 버전에서는 67 00:06:25,953 --> 00:06:27,953 이미지 검색이 하나의 태스크가 됩니다. 68 00:06:28,453 --> 00:06:34,101 태스크를 하나 생성하여 디렉토리 훑기를 시작하는 것이죠. 69 00:06:35,410 --> 00:06:37,410 이미지를 발견하면 70 00:06:37,910 --> 00:06:39,910 메시지를 보낼겁니다. 71 00:06:42,560 --> 00:06:44,560 이 경우엔 alternator라는 놈한테 보냅니다. 72 00:06:45,407 --> 00:06:51,046 16-way 컴퓨터에서 돌리는 반면, 제 파이프라인은 매우 작기 때문입니다. 73 00:06:51,635 --> 00:07:00,125 그리고 필터들이 완전히 병렬적이지 않아서 입니다. 직렬 버전과 병렬 버전이 있는데요, 이는 의도된 것입니다. 74 00:07:00,213 --> 00:07:05,594 행렬 곱셈이나 광선추적 같은 실제 적용 상황을 흉내내기 위해서입니다. 75 00:07:06,887 --> 00:07:10,952 이 로드밸런싱 단계는 그 파일 정보를 일련의 transform에 전달합니다. 76 00:07:11,188 --> 00:07:17,680 실제 alternator는 이용가능한 첫 transform을 택해 그리로 전달합니다. 77 00:07:17,945 --> 00:07:20,779 transform은 그 경로를 가지고 78 00:07:20,868 --> 00:07:25,489 GDI+ 함수를 이용해 디스크로부터 이미지를 읽어옵니다. 79 00:07:28,014 --> 00:07:32,768 그 다음에는 내부에 일련의 parallel_for를 가지는 이미지 필터를 호출합니다. 80 00:07:35,470 --> 00:07:43,397 이미지필터는 공유 메시지버퍼에 메시지를 보내 81 00:07:43,897 --> 00:07:50,699 작업 완료 상황을 알 수 있게 합니다. 82 00:07:51,962 --> 00:08:02,321 그리고나서 렌더링을 하게 되는데, GUI는 단일 스레드 모델을 사용하므로 거기서 렌더링도 이루어지게 됩니다. 83 00:08:07,342 --> 00:08:13,837 디렉토리 훑기부터 살펴보죠. 84 00:08:16,568 --> 00:08:18,568 여기 traverse_directory 호출이 보입니다. 85 00:08:20,183 --> 00:08:22,183 이건 직렬 버전이고요, 86 00:08:23,240 --> 00:08:24,753 여기서 이미지 카운트를 증가시킵니다. 87 00:08:24,783 --> 00:08:32,431 이 부분은 락이 필요한데 실제 interlocked 연산을 사용합니다. 88 00:08:32,520 --> 00:08:35,837 이 부분을 제외하고는 락 없이 메시지만으로 동작합니다. 89 00:08:37,452 --> 00:08:40,410 그 다음에는 현 파일경로를 직렬로 파싱합니다. 90 00:08:42,290 --> 00:08:44,290 병렬 버전은 91 00:08:46,668 --> 00:08:48,668 두가지 점에서 흥미롭습니다. 92 00:08:49,168 --> 00:08:55,563 첫째로, traverse_directory에 대한 재귀 호출을 태스크 스케줄로 바꿉니다. 93 00:08:55,711 --> 00:09:00,897 태스크그룹으로 하부디렉토리를 재귀적으로 스캐닝하게 하고 있습니다. 94 00:09:01,250 --> 00:09:06,832 실제 하부디렉토리와 마주치면 또다른 태스크로 스케줄링 합니다. 이 경우에는 모든 것이 로컬이죠. 95 00:09:07,684 --> 00:09:18,167 하지만 실제 먼곳에서 있는 공유 파일들에 접근한다 가정하면 진행 상태가 매우 안좋을 수 있습니다. 96 00:09:18,667 --> 00:09:25,176 그런 경우 네트워크 접근 지연 때문에 블록킹되는 것은 바라는 바가 아닐 겁니다. 97 00:09:26,531 --> 00:09:29,864 그 다음에는 바로 그 자리에서 파싱하지않고 98 00:09:30,364 --> 00:09:32,364 메시지를 보내고 있습니다. 99 00:09:32,599 --> 00:09:38,927 여기서 경로들의 unbounded_buffer인 이미지버퍼에 100 00:09:39,427 --> 00:09:41,427 현재 파일경로를 보냅니다. 101 00:09:42,015 --> 00:09:45,393 이 파일경로는 wstring인데요, 자막제작: 정재원(all2one) http://vsts2010.net http://gl3d.net