NDC Replay

시즌 2 : 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
정내훈
한국산업기술대학교
엔씨소프트에서 리니지포에버 프로그래머, Alterlife와 Project M(블레이드 앤 소울) 프로그램팀장을 하였음. 현재 한국산업기술대학교 게임공학과에서 부교수로 재직 중.
NDC2012에서 발표한 내용의 다음 이야기 입니다. 많은 프로그래머들이 들어는 보았으나 제대로 알고 활용하기 어려운 Non-blocking Programming에 대해 알아봅니다. 가장 널리 쓰이는 non-blocking 구현방법인 Lock-Free 프로그래밍에 대한 알기 쉬운 설명과 함께 실제 MMOG서버를 구현했을 때의 성능 향상 결과를 공유합니다. 또한, 멀티쓰레드 프로그래밍의 새로운 대안인 Hardware Transactional Memory에 대해 살펴보고 실제 Intel Haswell 프로세서 상에서의 성능과 함께 가능성과 한계에 대해 이야기합니다.
[새 창에서 슬라이드 보기]
올해는 ‘시즌2 : 멀티쓰레드 프로그래밍이 왜 힘드나요?’ 두 번째 버전을 하겠고요. 답은 2년전에 들어보신 분은 아실 거에요. ‘왜이리 힘드나요?’ 원래 힘들어요. 이렇게 힘든 거니까 따라 오실 분은 따라 오시고 힘드시면 포기하시는 게 낫다. 그게 답이죠. 그런데 여기 모이신 분은 하겠다는 강력한 의지를 가지고 오신 거에요. 그러니까 끝까지 한번 들어 보세요. 저는 카이스트 전산과 박사. 원래 이런 거 잘 안 쓰는데 쓴 이유는 어제 전길남 박사님 강의 들었어요. 컴퓨터 네트워크 강의 들었고, 송재경 사장님 오셨는데 옆에서 같이 놀았어요. 송사장님은 일찍 과학원을 그만 두셨고 저는 끝까지 남아서 버티고 늦게 게임판에 뛰어 들었죠. 거기서 차이가 난 것 같습니다. 그래서 졸업한 다음에 NCsoft에서 근무를 했습니다. 그땐 부사장이었죠, 저를 낙하산으로 꽂아서 이런 거 개발했는데 잘 안 됐어요. 지금은 학교에 있어서 NC에서 배운 거를 바탕으로 해서 게임 서버 프로그래밍, 멀티코어 프로그래밍. 이런 과목들을 강의하고 있습니다. 오늘 발표드릴 내용은 제가 현장에서 멀티쓰레드 프로그래밍, 요구가 굉장히 많았습니다. 그래서 가서 제가 강의하고 그런 내용을 압축한 거에요. 앞부분 압축한 건 2년전에 해드렸고 오늘은 뒷부분을 압축한 거에요. 지금 삼성 첨단기술연구소하고 CJ E&M에서 강의 중인데 오늘도 가봐야 되요. 오후 늦게 듣고 싶은 강좌가 많은데 몇 개 못 듣게 돼서 참 애석합니다. 오늘 할 내용은 네 개. 그래도 멀티쓰레드 프로그래밍을 하시려고요? 멀티쓰레드 프로그래밍 하면 안 되요. 제가 하는 발표 들어보신 적 있으신 분? NDC나 CJ E&M, KDC. 전부 새로운 얼굴들이시네요. 멀티쓰레드 프로그래밍 경험 있으신 분? 많으시네요. 2년전보다 많이 늘었습니다. 혹시 look-free 자료구조. 뭔지 아시는 분? 써보신 분? 만들어보신 분? 한 분. 아직 좀 어렵네요. 그래서 이 강의가 있는 거에요. 멀티쓰레드 프로그래밍 하시면 안 되요. 왜? ‘자꾸 죽는데 원인을 알 수가 없어요.’ 또 ‘이상한 값이 나오는데 이유를 모르겠어요. 더 느려져요.’ 싱글쓰레드 돌렸을 때 속도가 안 나오네? 했는데 멀티쓰레드 하니까 더 느려져요. 왜 그래요? 멀티쓰레드 프로그래밍의 단어는 우리나라 말로 변역하면 흑마술, 마공. 이런 거에요. 위력이 강대하나 다루기 어려워서 잘 쓰이기 어려운 기술. 패가망신하죠? 잘못 배우면. 마찬가지에요. 왜 패가망신하고 왜 죽느냐? 이런 이유 때문에 한 페이지. 이게 1년전에 한 내용입니다. 왜 이상한 값이 나오느냐? 루프 돌면서 5천만번 더했는데 왜 1억이 안 나오냐? Data Race 때문에 이건 Lock을 사용하고, Lock을 사용했더니 올바른 결과는 나오는데 왜 10가 느려지느냐? 싱글쓰레드 했을 때보다. Lock을 썼으니까요. 느려지는 거고 그래서 해결책은 Lock을 쓰면 안 되요. 절대 빨라질 수 없어요. Lock을 쓰는 한. Lock을 없애야 되는데 Lock을 없앴더니 컴파일러가 내가 읽으라고 한 값을 읽지 않아요. 그냥 막 무시해요. 어떻게 해결해야 되요? Volatile 키워드로 해결하고, 요새 또 좋은 게 나왔죠? C++11, 아토믹 키워드로 해결하실 수 있어요. 또 컴파일러로 옮겼더니 CPU가 여러분이 짠 프로그램을 지 멋대로 순서를 바꿔서 뒤죽박죽 수행해서 결과가 엉터리로 나와요. 어떻게 해야 되요? Mfence 명령 넣어서 바꾸면 안 되는 분을 바꾸지 마라. 라고 여러분이 직접 명령을 내리셔야 되요. 아니면 아토믹 쓰시던가. 아토믹 쓰시면 컴파일러가 이거 넣어줘요. Mfence. 꼭 이거 넣어주지는 않고 다양하게 넣어 주는데 하여튼 재는 맞춰줘요. 그리고 또 integer 변수가 있는데 거기다 -1을 여러분이 썼어요. 그런데 -1이 써지지 않고 이상한 값이 써져요. 왜 그런가? Cache 라인의 바운더리에 걸쳐있는 포인터를 썼기 때문에, 그게 무슨 얘기냐? 지난번 강의 ppt 올려져 있으니까 검색하시면 나와요. 거기서 보시면 되요. 그리고 끝날 때 이 강의 pt랑 똑같이 올려놓은 거 ftp사이트 주소를 알려드리겠습니다. 거기서 다운로드 받아서 보시면 되요. 이래서 멀티쓰레드 프로그래밍이 어려운데 이게 다가 아니에요. ABA문제가 또 있어요. 굉장히 골치 아픈 문제인데 어떻게 해결하느냐? 아마 내년쯤 하지 않을까? 이게 다에요. 이거 말고 딴 건 없어요. 이것만 다 해결하시면 여러분도 흑마술의 대가가 되어 있어요. 쉽지 않아요, 흑마술의 길이. 이렇게 서두를 뛰고 그래서 지난번에 한 내용은 이렇게 어려운데 성능 문제도 있고, 올바른 값이 나와야 되고, 어떻게 풀어야 되느냐? Look-free 프로그래밍을 하세요. 라고 얘기를 하고 끝냈습니다. 그럼 lock-free 프로그래밍이 뭐야? 이런 대답이 나오겠죠. 그래서 오늘 두 번째 세션을 준비한 거고요. 현실에서 멀티쓰레드 프로그램, 상용 프로그램들 어떻게 돌아가고 있는가? 많은 상용 게임들이 멀티쓰레드에서 돌아가고 있어요. 심지어 NCsoft 같은 곳에서는 10년 전부터 송재경 부사장이 멀티쓰레드로 구현했죠? IOCP써서. 멀티코어에서 여러 쓰레드가 동시에 실행되면서 성능을 높이고 있는데 쓰레드 간에 서로 협력을 해야 되요. 동기화 하고 데이터를 주고 받고 해야 되는데 어떻게 하느냐? Lock-free 자료구조를 통해서 해야 되요. 안 그러면 성능이 나오지 않아서. 그래서 각종 게임 서버, 뒤에 가서 보여드릴 텐데 lock-free 자료구조 사용하고 있고, 이거 사용하면 동접이 3000넘기 힘들어요. 요새 게임 엔진들 다 멀티쓰레드로 돌아가죠? 쓰레드간의 자료구조, 쓰레드 데이터 교환, 다 lock-free 자료구조로 하고 있습니다. 언리얼3 lock-free이긴 한데 사기스러운 거에요. 따로 기회가 있으면 말씀 드리고. Lock-free 알고리즘을 왜 사용해야 되는가? 사용하지 않으면 성능이 개판이 되기 때문에 사용하는 거고, 왜 사용하지 않으면 개판이 되느냐? 병렬성 감소. Lock을 걸면 lock이 걸린 부분이 실행되는 동안 다른 쓰레드는 lock이 걸린 부분을 실행할 수가 없죠? 그러니까 동시에 실행 되야 빨라지는데 동시에 실행되지 않고 차례차례 실행되니까 싱글쓰레드랑 다를 바가 없어져요. 그래서 빨라지지 않아요. 그리고 Priority Inversion, Convoying. 이런 일들 때문에 렉이 걸리고 버퍼에 데이터가 쌓여서 버퍼 오버플로어 나고 난리가 벌어져요. 지난번에 보여 드렸어요. 그래서 lock-free 알고리즘을 사용하게 되는데 lock-free 알고리즘이 뭐냐? ‘여러 개의 쓰레드에서 동시에 호출했을 때에도 정해진 단위 시간마다 적어도 한 개의 호출이 완료되는 알고리즘.’ 사전적 정의인데, 교과서에 있는 내용인데, 뭔지 잘 모르시죠? 이해가 잘 안 되요. 알고리즘은 뭐에요? 알고리즘은 자료구조, 그리고 그 자료구조에 접근하는 방법이죠. QUEUE 라는 자료구조가 있으면 인큐, 디큐 하고. Stack은 push, pop하고. 바이너리 트리다. 그러면 insert, delete, search. 이게 알고리즘이에요. 여러분 수업시간에 다 배우셨죠? 지금 작성해라. 그러면 쉽게 작성하실 수 있을 거에요. 이런 간단한 자료구조는. 그런데 lock-free가 앞에 붙으면, ‘lock-free 알고리즘이 도대체 뭐냐?’ 이건 멀티쓰레드에서 동시에 호출해도 정확한 결과를 만들어 주는 알고리즘. 그러니까 여러분 대학교 2학년 때 짠 앞에 뭔 알고리즘은 lock-free 알고리즘이 아니에요. 왜? 멀티쓰레드에서 재대로 동작하지 않기 때문에. 여러분이 수업시간에 짠 알고리즘 멀티쓰레드에 동작시키면 그냥 죽어버려요. 왜? 아까 말씀 드렸죠? 데이터 베이스 때문에. 그래서 여러분이 많이 쓰는 STL 탈락. 멀티쓰레드 안 돌아가요. 부스트 탈락. 안 돌아가요. 그리고 lock-free 알고리즘이 되려면 Non-blocking 알고리즘이어야 되요. 이건 뭐냐하면 lock을 쓰지 않는다. 로는 부족하고, 다른 쓰레드가 어떤 상태에 있건 상관없이 호출이 완료된다. 이 개념은 다른 쓰레드가 뭘 해주는 걸 기다리지 않아요. 다른 쓰레드가 플래그를 세팅해 주길, 다른 쓰레드가 lock을 풀어주길, 다른 쓰레드가 자기 순서가 끝내길 기다리지 않고 그냥 돌아가야 Non-blocking이고 non-blocking 중에 lock-free가 될 수 있어요. 이건 조금 이해가 될 듯 말 듯 하시죠? 넘어가시면 되요. 또 이야기가 나오니까. 그리고 호출이 다른 쓰레드와 충돌했을 경우, 적어도 하나의 승자가 있어서 승자는 delay 없이 완료된다. 이건 뭐냐하면 큐에 인큐라는 메소드가 있죠? 호출을 했는데 싱글쓰레드로 호출하면 잘 돌아가요. 그런데 멀티쓰레드에서 동시 호출해서 어떻게 해야 되느냐? lock-free알고리즘이다. 그러면 세 개의 쓰레드가 동시 호출했을 때 적어도 하나는 완료를 해서 결과를 리턴해야 그래야 lock-free알고리즘이에요. 세 개의 쓰레드가 다 완료한다. 동시에. 그러면 lock-free이기도 하고 더 한 단계 높은 Wait-free 알고리즘이기도 하죠. 모든 쓰레드가 delay없이 완료되면. 여기서 여러분들이 유념해야 될 것이 여러분 프로그램에 lock이 있어요. Lock을 넣었다, 그러면 무조건 lock-free알고리즘이 아니에요. Blocking 알고리즘이고. 하지만 lock을 사용하지 않았으니까 내 프로그램은 lock-free 알고리즘이다. 절대 아니에요. Lock을 사용하지 않아도 대부분의 알고리즘이 blocking 알고리즘이에요. lock-free가 되려면 정말 조심해서 작성하셔야 되고, 어떻게? 계속 나옵니다. 그래서 지구상에는 수많은 알고리즘이 있는데 두 종류로 나눌 수 있어요. 여러분이 지금까지 배운 싱글쓰레드 알고리즘. 이거 뭐에요? 멀티쓰레드로 돌렸을 때 뻑 죽고 이상한 결과가 나오는 알고리즘들. 그리고 멀티쓰레드에서도 잘 돌아가는 알고리즘이 있죠. 멀티쓰레드에서도 잘 돌아가는 알고리즘은 당연히 싱글쓰레드에서도 잘 돌아가고. 멀티쓰레드 알고리즘은 크게 두 종류로 나눌 수 있어요. Blocking, non-blocking. Lock을 사용하면 무조건 blocking이고 lock을 사용하지 않았더라도 일부분은 non-blocking, 일부분은 blocking. Non-blocking이 좋은 알고리즘이죠? Non-blocking중에서도 여러 가지 등급이 있는데 lock-free인 거, lock-free가 아닌 거 있고. lock-free인 알고리즘 중에서는 wait-free 알고리즘이 있고 lock-free인데 아직 wait-free는 아닌 거. 이런 알고리즘들이 있습니다. 이렇게 분류를 할 수 있고, 여러분한테 지금 알려드릴 내용은 lock-free알고리즘. Blocking 알고리즘은 뭐가 있어요? 이런 게 있죠. “sun=sun + 2” 이것만 있으면 멀티쓰레드 알고리즘이 아니에요. 멀티쓰레드에서 이상한 값이 나오니까 멀티쓰레드 알고리즘이 되려면 lock을 붙여야죠? Mutex. q 라는 QUEUE가 있고 거기를 35로 표시한다. 싱글쓰레드 알고리즘이에요. 멀티쓰레드 안 돌아가고 멀티쓰레드로 돌리려면 lock을 걸어야 하죠? 그리고 이런 프로그램을 짰어요. 멀티쓰레드에서 여러 쓰레드가 돌아가는데 dataready가 틀릴 때까지 기다렸다가 dataready면 g_data를 읽어서 내가 작업을 하는, 이런 프로그램을 짰다. 다 blocking이에요. lock없죠? blocking이에요. 왜? 다른 쓰레드에서 이걸 ture 할 때까지 내가 기다리니까 blocking 알고리즘이에요. Blocking이 아니라면 기다리면 안되고 그냥 내려가야 되요. 무한 대기, 하루 종일 기다리니까 blocking이에요. 다른 쓰레드가 왜 얘를 안 해주고 기다리게 만들어요? 여러 가지 이유, cache 미스돼서 200 클락 쭉 밀릴 수도 있고 schedule out.도 실행되니까 잠깐 쉬어. 라고 운영체제가 내보낼 수도 있고. 여러 가지 이유로 밀릴 수가 있어요. 앞에 알고리즘 non-blocking하게 바꾸면 어떻게 바꾸냐? sum에다 2를 더하는 걸 non-blocking하게 바꾸면 이렇게 바꾸면 되요. Asm lock. 이거는 이 명령을 non-blocking lock-free으로 실행해라. 라는 x86 기계어에요. 이렇게 해주면 sum에다 2를 더하는 이 오퍼레이션이 atomic하게 non-blocking으로, lock-free로 돌아가요. 그러면 명령 하나로 끝났는데 push하는 건 어떻게 하느냐? 이렇게 해주셔야 되요. push니까 새로운 노드를 만들어서 tail을 읽어서 tail에다가 추가를 하고. 이런 식으로 만드셔야, lock 없죠? Lock없이 멀티쓰레드에서 동시에 해도 잘 돌아가는 non-blocking, lock-free 알고리즘이 되요. 복잡하죠?  얘는 blocking인데 얘를 lock-free로 만들려면 어떻게 해야 되느냐? 불가능해요. 프로그램 자체가 그렇게 되어 있으니까. 이거는 프로그램 자체를 개조해야 되요. 어떻게? 파일 루프 없죠? Dataready가 false면 ‘그냥 더 안 할래’ 하고 빠져나가서 다른 거 하게 해줘야 되요. True면 “temp = g_data” 받으면 되고요. 이게 non-blocking 버전들이에요. 그런데 여기 CAS. 이거 있죠. CAS 예전에 말씀 드렸어요. CAS는 lock-free의 핵심 키워드이고 반드시 하드웨어로 구현이 되어야 되요. 소프트웨어로 절대 구현할 수 없고 하드웨어로 구현이 되야 되고 여러분이 쓰는 cpu, x86, 암, 알파, power PC 다 있어요. CAS 명령이. 이걸 사용해서 Non_blocking 알고리즘을 구현해야 되고 이거 없이는 구현할 수 없다. 라고 증명 되어 있어요. 그러니까 헛된 노력하지 마세요. 이거 없이 어떻게 non-blocking할 수 있을까? 절대 안 되요. CAS를 사용하면 모든 싱글쓰레드 알고리즘들을 lock-free알고리즘으로 변환할 수가 있어요. 여러분이 작성해서 여러분의 게임에서 쓰는 바로 그 알고리즘, 멀티쓰레드 lock-free로 바꿔 쓸 수가 있어요. CAS를 사용해서. 어떻게 바꿀 수 있느냐? 프로그램을 보여드렸어요. 지난번 발표할 때. 찾아보시면 되고요. lock-free를 써야 되는 왜? 성능 때문이에요. 성능이 아니면 그냥 lock을 쓰면 되요. 성능 때문에 lock을 못 쓰고 lock-free을 사용해야 되고, CAS가 필요해요. 이거 없이는 lock-free알고리즘 만들 수 없다. 증명이 되어 있어요. CAS는 뭐냐, A라는 변수에 new라는 값을 넣었는데 그냥 넣는 게 나이라 A에 old가 들어있으면 new로 바꾸고 A가 old가 아니라 다른 이상한 값이 들어있다. 그러면 실패하고 false를 리턴하는 그런 오퍼레이션이 CAS에요. 이건 사전적 의미고 non-blocking에서 이걸 어떻게 쓰느냐? lock-free에서는, A에 메모리를 다른 쓰레드가 먼저 변경했으면 ‘내가 새치기 당했구나. 포기하고 다른 데서 알아봐야지.’ 그런 의미에요. 여러 개의 쓰레드가 동시에 디큐, 인큐, push, pop 할 때 교통정리를 하는 거에요. 다른 쓰레드가 먼저 했으면 나는 하면 안 되는 구나. 다시 시도하게 해주는 키워드가 바로 CAS에요. lock-free 말씀 드렸는데 어떤 알고리즘이 lock-free에 동작한다. 이게 어떤 의미인가 하면 알고리즘이란 뭐에요? 알고리즘은 데이터 구조를 접근하는 방법이 알고리즘이요. 기존의 자료구조를 바꾸거나 add, remove하거나 구조를 바꾸거나, 아니면 자료구조에서 정보를 얻어내는 행위. 그게 알고리즘이에요. Push 알고리즘은 뭐에요? 여기 QUEUE가 있을 때 35로 표시한다. 그러면 여기에다가 35를 끼워 넣는, 이게 push알고리즘이죠? 알고리즘 동작은 머냐? 값을 읽어낼 거하고 자료구조를 바꾸는 거에요. 두 개중에 하나에요. 다른 건 없어요. 이거를 lock-free로 구현하겠다. 하면 어떻게 해야 되요? 이렇게 해야 되요. 자료구조를 변경해요. 싱글쓰레드에서 했듯이 변경하고 tale 바꾸고, tale에 있는 node에 포인터 연결하고 다른 쓰레드와 충돌했는가 봐요. 다른 쓰레드와 충돌했다고 하면 이게 재대로 돌아갔을지 틀렸을지 알 수가 없죠. 어떻게 해요? 다시 롤백. 다른 쓰레드와 충돌하지 않았다. 나 혼자만 실행을 마쳤다. 그러면 이건 잘못될 리가 전혀 없으니까 완료. 중요한 건 이거죠? 충돌했는가? 충돌했을 때 다시 원래대로 되돌리는 거에요. 그런데 이게 기본 아이디어인데 타임머신은 어떻게 구현해요? 불가능하죠? 불가능 하니까 lock-free는 이렇게 구현해요. 현재 자료구조는 어떻게 되었는가? 봐요. 그 다음에 내가 이 자료구조를 성공적으로 변경하면 다음에 어떻게 생겼을까? 그 모습을 설계해요. 그 다음에 한 큐에 변경을 시도해요. 시도했는데 시도가 성공했으면 완료. 실패했으면 다시, 다른 애가 바꿨으니까, 다시 또 파악을 해야 되요. 그래서 시도하고 하지만 다른 쓰레드가 먼저 변경을 했으면 내가 파악한 자료구조와 지금 자료구조가 다르죠? 그럼 다시 하고. 이게 lock-free 알고리즘이고 이게 핵심이에요. 다른 쓰레드가 변경을 했으면 내가 변경하지 않고 취소하는 거. 어떻게 해요? CAS로 해요. ‘Sum=sum + 2.’ Lock, lock, unlock 블로킹 알고리즘이죠? 이걸 non-blocking으로 바꾸면 어떻게 되요? Lock을 없애야 되고 lock을 없애면 재대로 안 돌아가니까 아까처럼 지금 현재 자기가 하고 있는 현재 상태를 파악해요. 지금 이 sum이란 자료구조 현재 상태는 이 값을 가지고 있네. 파악한 거에요. Old sum. 한 큐에 바꿔요. 어떻게 바꿔요? Sum에 있는 값을 old sum + 2로 바꾸는 데 그냥 바꾸면 어때요? 덮어써버리죠? 그러니까 이 sum을 다른 쓰레가 와서 old sum이 아닌 다른 값으로 변경시키지 않았을 경우에만 old_sum+2로 바꾸는 게 바로 이 CAS에요. Sum을 다른 애가 바꾸지 않았으면 2를 더한 값으로 바꿔라. 성공했으면 끝이죠. 실패했으면 처음부터 다시. 이게 lock-free로 구현하는 sum = sum + 2 알고리즘이에요. 간단한 게 복잡해졌죠? 이런 거에요. Push 어떻게 했어요? Tail에 새 노드 만들고 tail이 가리키는 끝 노느죠? 거기에 이걸 추가한 다음에 tail이 얘를 가리키게 하는, 두 줄로 끝나는 QUEUE의 구현이에요. Non-blocking으로 구현하면 어떻게 되요? 이렇게 되요. 현재 자료구조, tail은 이 값을 가지고 있고 tail 노드의 next는 이 값을 가지고 있고 tail node의 next가 null이 아니면 ‘tail node 뒤는 당연히 null인데?’ 당연히 null이 아니죠? 다른 쓰레드가 와서 내가 읽은 다음에 막 바꿀 수가 있어요. 값을, 이 사이에 와서. 고장이 없어요, null이라는. 검사를 해야 되요. 내가 tail을 읽었는데 다른 쓰레드가 와서 tail값을 막 바꿀 수 있죠? 그럼 실패한 거에요. 다시 처음부터. Tail은 다른 쓰레드가 바꾸지 않았어. 그러면 이걸 해야죠. 이걸 하는데 그냥 하면 다른 쓰레드랑 충돌나서 막 꼬여요. 그래서 CAS로 바꿔야 되요. 한 큐에. Tail의 next는 얘가 다른 쓰레드가 바꾸지 않고 아직 null이다. 그랬을 때 e로 바꾸는 거고 tail, tail이 내가 아까 읽은 값 그대로 유지되고 있다. 다른 쓰레드와 바꾸지 않았다. 그러면 tail을 e로 바꾸고 그러면 이제 non-blocking이에요. lock-free로 구현된 push 알고리즘이에요. 그런데 이게 돌아가지 않아요. 왜? 이런 게 없어요. 이런 명령어가 cpu에 없어요. 암에도 없고, x86에도 없고, 알파에도 없고, power PC에도 없고, 다 없고. 옛날 옛날 매킨토시에 있었던 68020시리즈, 30시리즈에는 비슷한 게 있었어요. 그런데 지금은 없어요. 아무도 이런 걸 구현하지 않아요. 그래서 어떻게 해야 되냐? 이거 한 큐에 바꿔야 되는데 한 큐에 못 바꾸니까 CAS를 여러 개 바꿔야 되고 CAS를 여러 번 하면 CAS와 CAS사이에 다른 쓰레드가 끼어 들어서 tail을 바꾸고, next바꾸고, 막 난리를 칠 수가 있어요. 그래서 뒷수습을 해줘야 되요. 이렇게. 알고리즘이 복잡해집니다. 이거 한 큐에 이해되죠? 이걸 들어보니까 이해가 되요. 이거 이해가 안 되요. 30분동안 설명을 드려야 이해가 되요. 그래서 작성시 실수하기가 쉽고, 에러가 나도 적발이 힘들어요. 어떤 일이 벌어져요? 게임서버를 해서 돌려요. 만들어서 유닛 테스트해요. 잘 돌아가요. 클베 잘돌아가요. 오베? 하루에 한 두번 서버가 죽어요. 매우 낮은 확률로 가끔가다 아이템이 증발하고 서버가 죽고 렉 걸리고. 이유를 알 수가 없어요. 이유는 뭐였어요? 실수를 했는데 어디서 실수했는지 찾기가 힘들어서 실수를 발견하지 못한 거에요. 그런 일이 많이 생겨요. 그래서 재대로 동작한다는 것이 증명된 알고리즘을 사용해요. 인터넷에서 ‘이 알고리즘 괜찮아 보이는데?’ 하고 lock-free알고리즘이라고 copy&taste 했으면 낭패를 겪게 됩니다. 실제 그런 일이 많이 생겼어요. lock-free알고리즘. 장점은 성능. 오로지 성능. 무조건 성능. 그리고 높은 부하에도 안정적. 여러분이 lock-free로 짰는데 이거 그냥 내가 프로그램을 잘 리팩토링해서 lock을 최소화 했더니 lock-free한 것보다 빠르네요? 있어요 그런 경우. 있을 수 있는데 부하가 높아지면 못 버텨요. Lock을 사용하면. Non-blocking, lock-free를 사용하면 부하가 높아져도 그렇게 많이 안 느려져요. 락보다. 그래서 서버 만들 때 어떻게 만들어야 되요? 부하가 적을 때 잘 돌아가고 안 돌아가고 아무 상관이 없어요. 부하가 최대 부하가 걸려서 동접 5000짜리 서버가 아닌데 동접 5000이 와서 동선 제한하고 그럴 때 어떻게 해야 되요? 그러면 Non-blocking 자료구조 쓰지 않으면 안 되요. 평소에 잘 돌아가다가 이벤트하면 죽고. Lock-free 알고리즘 쓰지 않았기 때문에 그래요. 단점은 뭐에요? 아까 보셨죠? 복잡해요. 생산성이 떨어져요. 그냥 큐는 10분이면 짤 수 있어요. 그런데 Lock-free 큐를 만들어라. 며칠 고생을 해야 되요. 그리고 정확성을 증명하는 게 어려워요. 아까 프로그램이 정확하다. 증명 되어있어요. 하지만 교과서에 나온 알고리즘이고, 1줄, 1줄 모든 경우에 대해서 다 all correct하다는 게 증명이 되어 있어요. 그러니까 안심하고 쓰는 거에요. 그리고 확장성. 잘 돌아가는데, 인큐, 디큐, 메소드는 잘 구현해서 돌아가는데 디큐할 때 두개를 동시에 디큐하는 메소드를 만들어야겠다. 너무 어려워요. 구현하는 건 아닌데 어렵고 디큐만 바꾸면 되는 게 아니라 인큐까지 같이 바꿔야 되요. 모든 메소드를 다 같이 동작하도록 손을 봐야 하는데 너무 어려워요. 그래서 하다가 새로운 메소드가 필요한데. 그러면 멘붕을 겪어요. ‘이거 어떻게 하지?’ 불가능하니까. 그리고 메모리. 다이나믹 자료구조, 포인터 없으면 new, delete 하죠? 사실 new, delete 는 안 해요. 하지만 재활용은 해야 되요. 그런데 어려워요. 왜냐하면 lock없이 쓰레드가 동시에 돌아가기 때문에 이 데이터를 내가 delete 해야 될까 말아야 될까 판단하기가 힘들어요. 그리고 ABA문제. 이거는 1시간짜리이고 내년에 아마 할지는 모르겠습니다. 이런 것 때문에 힘들어요. 그래서 믿을 수 있는 non-blocking container. 인텔에서 만든 거 MS에서 만든 거. 이런 거 사용하면 괜찮은데 여러분이 인터넷에서 긁어오든가 커스텀하게 만들었다. 정확성은 증명하고 사용하세요. 이거 안 했다가 피 본 케이스 많이 봤습니다. 정말 조심해서 사용하셔야 되요. 그렇게 힘든데 과연 성능이 나오느냐? 나와요. 동접 1만 서버를 만들어보죠. 1000x1000 월드. 그리고 60단위로 섹터를 분할해서 시야 처리를 하고 내 주위에 30미터 시야를 클라이언트에서 볼 수가 있고 1000마리의 몬스터. AI로 돌아가고 플레이어가 접근하면 와서 때려주고 이동하고 공격, 채팅하고. 이런 서버를 구현했어요. 작년 제 과목 팀 프로젝트로 구현 한 건데 제가 짠 서버를 안 쓰고 왜 이걸 쓰느냐? 제가 짠 서버는 UNITY에서 돌아가는데 그 unity는 공개가 불가능해요. 상용이니까, 그래서 이걸 사용했습니다. 그래서 성능 향상을 위해 Lock-free 알고리즘을 사용했어요. 시야 처리시 검색 성능 향상을 위해서 월드를 섹터로 분할하고 섹터 검색할 때 병렬 검색을 해야 하니까 concurrent_hash_map 을 사용했고, 몬스터 AI 처리를 모든 워커 쓰레드가 균등하게 나눠서 처리하기 위해서 timer와 event 시스템 했는데 timer queue, concurrent_priority_queue. Lock-free priority queue 를 사용했고 객체 id의 재사용을 막고 그리고 id는 재사용 안되지만 메모리는 재사용 하기 때문에 id와 자료구조 객채배열의 인덱스를 쌍으로 관리 했는데 concurrent_hash_map을 사용해서 병렬 검색, 추가 삭제 해주게 했어요. 그리고 동접 10000. 어떻게 테스팅하느냐? 10000대의 PC로 하느냐? 힘들죠? 큰 회사나 할 수가 있어요. DummyClient를 사용했어요. 클라이언트를 띄우면 걔가 아이디를 10000개 만들어서 접속을 해요. 그러면 서버는 클라이언트가 10000개 들어와서 돌아가는 거에요. 그런데 사실은 컴퓨터는 10000대 쓰지는 않죠. 1~2대 써서 서버에 부하를 걸 수 있도록 에뮬레이션 해주는 프로그램이고 사람의 플레이 비슷하게 플레이어를 주기적으로 이동시켜요. 그리고 잘 만들면 전투도 하고 퀘스트도 하는데 거기까지는 안 했고요. 한 명의 유저당 하나의 소켓 연결을 하니까 일반 클라이언트 접속과 DummyClient 접속이 차이가 없어요. 그래서 멀티쓰레드 프로그래밍할 때 테스팅 해줘야 되죠? 죽나 안 죽나. 그리고 내가 이렇게 바꿨을 때 성능이 좋아지나 안 좋아지나 테스트를 해야 하는데 클라이언트 한 두 개에 접속해서 테스트하면 알 수가 없어요. Full로 부하를 걸어봐야 되요. 동접 8000서버다 8000 해봐야 내가 고친 게 재대로 돌아가나 검증이 가능하고 이때 사용할 수가 있겠죠. 한 줄 고칠 때 마다 사장님한테 10000명 클베 해주세요. 절대 안 되요. 그러다 보니까 이것 조차 IOCP로 구현돼서 서버로 돌아가고 이런 식으로 돌아갑니다. 바로 그 게임이에요. 2D게임이고 가운데가 플레이어고 주위에 다른 플레이어들 보이죠? 시야처리 되어있고 시야 벗어나면 안보이고. 8000, 동접 8000이에요. 1만 동접이라고 했는 왜 8000이냐? 테스트 클라이언트랑 서버랑 같은 컴퓨터에서 돌아가요. 동접 16000이에요, 사실. 잘 돌아가느냐? 잘 돌아가요. 보여드리죠. 노트북에서 돌리면 과연 잘 돌아갈까? 서버가 돌아갔습니다. 그 다음에 클라이언트를 돌려보죠. 클라이언트가 돌아갔어요. 내가 주위에 몬스터가 돌아다니고 있는데 동접은 1이에요. 동접 8000을 만들어보죠. 동접 5천까지는… 6000… 6700 돌아가고 있죠? 동접이 막 들어가니까 여기 주위에 플레이어들이 마구마구 생성돼서 돌아가고 있어요. 얘도 동접 8000 인데 돌아가고 있죠? 작업관리자 띄워서 서버 부하를 보면, 노트북이라서 조금 있으면 죽을 거에요. 얘가 동접 8000을 만들고 CPU 엄청 많이 쓰죠? 게임 서버는 별로 안 써요. 서버도 50쓰고 있고 지금 CPU를 이정도 쓰고 메모리 9G 쓰네요? 여유가 9G니까 한 5G 쓰고 있네요. 이런 노트북에서도 동접 8000이 되는, 그러니까 8000명이 서로 멀리 떨어져서 하면 쉬워요. 그런데 붙어서 브로드캐스팅까지 하면서 시야 공유하면서 하는 거는 상당히 부하가 가는 작업이에요. 그런데 되요. Lock-free를 사용했기 때문에 돌아가는 겁니다. 그래서 i7 920 테스트해보니까 동접 8000까지. Lock-free로 최적화 하기 전에 3000까지밖에 안 돌아갔어요. 3000까지만 가도 버벅거렸는데 8000까지 쭉 올라가요. 그러니까 Lock-free 프로그램을 사용하셔야 되요. 성능이 중요하고 여러분이 서버 기술, 서버 잘 돌아가기로 인정하는 유명한 회사들, N모사, B모사 다 멀티쓰레드로 구현하고 있어요. 자, 현실, 미래. Lock-free를 해야 되는구나. 앞으로 무슨 일이 벌어질까? 지금 무슨 일이 벌어지고 있느냐? 멀티쓰레드 세계가 계속 바뀌고 있어요. 그래서 제가 이 강의 PT도 작년에 KDC에서 했던 건데 그대로 쓸 수가 없어서 많이 바꿨어요. 작년에 무슨 일이 벌어졌어요? C++11이 나왔어요. C++11은 C++의 새로운 표준이죠. 앞으로 프로그래밍 할 때 C++11으로 프로그래밍 하셔야 되요. 이런 걸 꼭 써야 되느냐? C나 어셈블리로 할래. 안되죠. 이거 해야 되요. 제가 송재경 부사장한테 배운 교훈도 그런 거였어요. C로 프로그래밍 하고 있었는데 NC들어가니까 SQL을 쓰고 있더라고요. 2002년도에. 그때 SQL 버그도 많고 속도도 느렸는데 썼어요. 앞으로 쓰게 될 거고 생산성을 위해서 써야 된다. 지금 다 SQL쓰고 있어요. 서버에서. 멀티쓰레드가 안 되는데 왜 SQL써요? 멀티쓰레드 필요 없는 부분에 쓰고있어요. 그리고 SQL을 멀티쓰레드 화해서 쓰고 있어요. 그래서 여러분 이거 배우셔야 되고, 멀티쓰레드 표준 라이브러리에요. 옛날에는 리눅스에서 멀티쓰레드 하려면, 윈도우에서 멀티쓰레드 하려면, 그리고 ARM CPU에서 하려면, 안드로이드에서 하려면, 다 프로그램이 달랐는데 이거만 쓰면 어디서든 잘 돌아가요. 그래서 #include <thread>, #include <mutex>, #include <atomic>, #include <memory>. 이 네 개의 멀티쓰레드 관련 표준 라이브러리는 여러분이 사용하셔야 되고 이거 사용하면 지난번에 했던 게 잘 돌아가요. 그리고 Boost ASIO 라는 게 나왔죠? IOCP니 이폴이니 그런 거 했는데 C++11 하고 같이 돌아가는 ASIO쓰면 플랫폼에 상관없이 최적의 속도가 나와요. 이거 여러분이 관심을 가지셔야 되고, 그리고 왜 하필 작년 말부터냐? C++11, 2011이죠? 2011년엔 왜 이거 안 했냐? 컴파일러가 없었어요. 작년에 G++4.8 작년에 나왔고 Visual Studio 2013 작년에 나왔죠? 이때부터 이 네 개가 구현이 됐어요. 이전에는 구현 안 됐는데. 그래서 이젠 이거 쓰시면 되요. 그런데 이거 사용하시면 아무 문제가 없느냐? 그렇지 않아요. 초창기에요. 문제가 많아요, 아직. 성능 문제가 있어요. correct하게 돌아가는데 완벽하게 correct하냐? 좀 허점은 있긴 한데 여러분이 사용 곤란한 정도는 아니고 최적화에 문제가 있어요. Shared_ptr. 괜찮은 건데 성능이 안 나와요. 최적화가 덜 되어있고 mutex, native한 lock보다 성능이 느려요. 행동은 좋은데 성능이 느려서 아직까지 본격적으로 사용하기에는 문제가 있는데 개선될 거에요. Sql이 그랬듯이 C++11. 작년에 나와서 지금 바뀐 현실이고 여러분 이거 사용하셔야 되고, 그리고 멀티쓰레드 도우미가 있어요. 여러분이 lock_free 알고리즘. 어려운 거 써야 되냐? 여기 있으니까. Intel TBB, Visual Studio PPL. 이런 거 사용하시면 되고 OpenMP라는 것도 있는데 이건 별 도움이 안되니까 쓰고 싶으면 쓰는데 쓰는 데가 없어요. 그리고 CUDA, OpenCL, DirectCompute. 이건 GPU활용하는 거고 lock_free 그런 거랑 전혀 관계가 없어요. 이건 따로 공부를 하시는 거고. 그 외에 CK, Concurrency Kit이나 Noble Library 등등 여러가지 잘 돌아가는 검증된 알고리즘이 있으니까 한번 사용하시면 많은 도움이 될거에요. 하지만 현실은 암담해요. Lock을 썼다, blocking 알고리즘이다. 성능이 엉망이라서 동접이 오히려 떨어지고, lock_free. 높은 난이도로 인한 생산성 저하. 디큐, 인큐 만드는데 하루, 이틀, 사흘 걸리고, 일주일 걸리고 완벽하다고 증명해야 되고 증명 못하면 불안불안 마음 졸이며 써야 되고 이거 문제죠? 문제에요. 어떻게 해야 되요? 해결책이 나와 있어요. Transactional Memory를 쓰세요. Transactional Memory는 뭐냐? 옛날부터 연구 돼왔어요. 2010년에 Tim Sweeny 아저씨가, 언리얼 만든 아저씨죠?, 우리는 앞으로 Transactional Memory를 써야 될 것이다. 예언을 했고 현실이 됐죠? 이게 뭐냐? Lock_free 알고리즘 어떤 거였어요? 자료구조 변경하고 다른 데서 충돌했는데 충돌 안 했으면 완료. 충돌했네? 타임머신. 다시 처음부터 하자. 이거였는데 이걸 그냥 그대로 구현 한 거에요. 이렇게 프로그램 작성하면 어렵죠? 이거 문제가 많아요. 그래서 이렇게 만들자. 그런데 돌아가게 하자. 어떻게? Transactional Memory로. Transactional Memory로 구현하면 여러분이 짠 프로그램에다 충돌했을 때도 잘 돌아가라. 하면서 atomic이라는 주문을 넣어주면 잘 돌아가요. 멀티쓰레드에서 atomic하게, Non broking으로, lock_free하게 잘 돌아가요. 이렇게 프로그램 짜고 싶어요? 이렇게 프로그래밍 짜고 싶어요? 이게 당연히 좋죠? 이게 당연히 좋죠? 이렇게 돌아가는 게 Transactional Memory에요. 그렇다면 어떻게 사용하느냐? 다른 쓰레드와 충돌이 일어나는 구간이 있다. Transaction 선언을 한다. 여기 Transaction 이야. 다른 쓰레드와 충돌할 수 있으니까 잘 해줘. 하면 잘 돌아가요. 이게 전부에요. 그러면 멀티쓰레드에서 잘 돌아가요. 올바른 값이 나오고 lock_free로 돌아가고 성능도 괜찮아요. 이런 게 가능한가? 이건 마법이 아니냐? 마법까진 아니에요. 이렇게 구현하면 되요. Transaction 구간에서 읽고 쓴 메모리를 다른 쓰레드에서 접근했는지 계속 검사를 하고 내가 write를 했을 때 실제 쓰면 안 되요. 충돌하니까 write를 쓰지 않고 어디다 보존을 해뒀다가 알고리즘이 끝나면 다른 쓰레드에서 접근이 있는지 없는지 확인을 하고, 충돌했다. 여기서 한 거 다 무효. 하고 처음부터 다시 하고, 없었다. 이 업데이트 한 거, 저장해 놨던 거를 메모리에 한꺼번에 lock_free로 써버리고. 그러면 되요. 어렵지 않아요. 말은 쉬운데 구현 가능한가? 가능하죠? 모든 write를 라이브러리를 통해서 하면 되요. 소프트웨어 적으로 모든 구문을 읽고 쓰는 거를, 거기서 그냥 읽으면 안 되고, 읽고 쓸 때마다 등록을 해줘야 되요. 라이브러리에 Software Transactional Memory 라이브러리에 등록을 시켜주면 얘가 모아뒀다가 업데이트 하고 롤백하고. 라이브러리도 있어요. MS에서 구현한 것도 있고 Intel에서 구현한 것도 있고. 많이 있고 뒤져보면 산더미처럼 나오니까 적당한 거 가져다 쓰시면 되요. 그리고 하드웨어가 이거를 해주게 하는 방법도 있어요. Hardware Transactional Memory라고 부르죠? 장점은 높은 생산성. 싱글쓰레드 프로그램을 거의 그대로 쓸 수가 있어요. 이거 충돌할 수 있나요? atomic하고 Transaction으로 돌려. 그러면 잘 돌아가요. 단점, 소프트웨어는 모든 read, write를 등록해야 된다. 롤백해야 된다. 속도저하가 엄청 커요. 느려요. 하드웨어는 하드웨어가 필요하죠? 여러분 컴퓨터에서 안 돌아가요? 하드웨어가 지원 되야 되니까. 그리고 한계점도 있어요 쓰레드가 너무 많다. 성능 향상이 잘 안 되요. 왜? 롤백을 하죠? 충돌했으면. 충돌이 잦으면 롤백이 잦아서 성능향상에 한계가 있어요. 그래서 좋은데 쓰기는 힘들겠다. 그리고 멀티코어 CPU가 발전해서 8코어 이상에서 돌리면 오버헤드가 있어도 성능, 싱글쓰레드보다 나아지지 않을까? Tim Sweeny 아저씨도 마찬가지 생각이었는데 Intel에서 일을 저질렀어요. 작년 6월달에 HASWELL나왔죠? 하드웨어로 Transactional Memory가 되요. 아까 여러분이 한 프로그램 돌아가요. 멀티쓰레드에서, lock_free로. 나오자마자 샀어요. 잘 되요. 인텔이 구라를 한 게 아니에요. 복수개 메모리에 대한 Transactiona을 허용해요. 변수 여러 개 기록해뒀다가 한 큐에 업데이트하고 롤백하고 충돌검사 다 해줘요. 그런데 복수개. L1 Data Cache 크기만큼. 32kb까지 되는데 얘가 그냥 메모리가 아니죠? set associative cache니까, 9byte 트랜잭션 했는데 뻑 죽을 수가 있어요. 32k했는데도 잘 돌아갈 수가 있고 out_fight 했는데 죽을 수가 있고. 무슨 얘기냐? 교과서 보세요. set associative cache가 어떻게 생겼냐 보시면 되요. CPU에서 트랜잭션 실패했을 때 리커버리를 제공해요. 롤백해줘요. 롤백할 때 메모리의 내용을 원래대로 다 바꾸고 레지스터, 실행하느라고 레지스터 막 바뀌었죠? 롤백. 타임머신이에요, 그냥. 트랜지션 시작하면 지금 상태를 저장해뒀다가 실패하면 다시 그걸 읽어 들여서 아무 일도 없었던 것처럼 다시 시도를 하는 그런 방식을 구현했어요. 하드웨어로. Visual Studio 2012, update 2부터 지원하고 2013에서는 그냥 돌아가요. Sum + 2 이거를 CAS, lock_free가 아니라 Transactional Memory로 구현하면 어떻게 되느냐? 이렇게 하면 되요. _xbegin()해서 Transaction, atomic 선언을 해주고 여기 atomic 끝이나요. _xend 하면 이게 이 사이에 있는 게 atomic하게 돌아가요. 이건 뭐냐? 실패했을 때. Atomic Transaction 실패했을 때 어떻게 할 것인가? 다시 실행하라 는 거에요. 그렇게 하면 재대로 돌아가고 결과도 correct하게 나오고 Non broking lock_free에요. 이건 간단한 프로그램, 복잡한 프로그램인지 어떻게 되느냐? Linked_list로 구현된, 정렬된 집합에다가 원소를 추가하는 lock_free 프로그램을 Transactional Memory로 구현한 거에요. 검색하고 read 한 걸 본 다음에 remove하고 추가하는 걸 구현한 거에요. 그러니까 싱글쓰레드 알고리즘을 거의 고치지 않고 이거만 추가했는데도 잘 돌아가요. Lock_free로 구현했을 때, HTM로 구현했을 때 성능 비교를 해보니까 lock_free가 조금 빨라요. HTM보다. 왜 그래요? Lock_free는 우리가 고생해서 만들었는데 이렇게 아무 생각 없이 만든 것 보다 느리면 억울하죠? 몇 가지 이유가 있어요. 빠른데 거의 없어요. 성능 차이가. 5%? 2%? 성능 오차가 아니에요. 어떻게 해야 되요? 저 메모리 써야겠죠? 쓰세요. 올해부터 Transactional Memory구현하는 하스웰 서버, 제온 CPU가 나오니까 이걸 써서 서버를 구현하시면 생산성 문제에서 해방되실 수 있어요. 그런데 만능은 아니에요. 모든 알고리즘에 적용이 불가능해요. 왜? 하드웨어 용량. 그죠? 32k 장벽, 커요. 9byte에서도 뻑날 수 있다. 프로그램을 신경써서 손봐야 되요. 그리고 Nested Transaction이 불가능해요. 가지치는 거. 불가능. 가능하다고 되어있어요, 메뉴얼에는. 그런데 불가능해요. 이건 뭐냐하면 Nested는 바닥에서 fail했을 때 한 단계 올라가야 되는데 맨 밑에서 fail해도 저 위로 올라가버려요. 몽땅 다 fail해버리니까 Nest 라고 보기가 힘들어요. 그런 문제가 있고. 이게 커요. 모든 알고리즘에 적용 가능. 알고리즘을 Transactional Memory으로 해야지. 아싸하고 했는데 안 돌아가요. 여러 군데 부딪혀요. Lock을 chain으로 건다. 그래도 안되고 안에 new, delete 있으면 안 되요. New, delete가 메모리를 상당히 많이 읽고 쓰기 때문에 여기서 뻑이 나요. System call하면 안 되요, 또. new하면 system call하죠? 제한 사항이 상당히 많기 때문에 그렇게 제가 얘기한 것도 쉽지는 않고 lock_free 구현하는 것보다 3/1 정도 쉬운 것 같아요. 그래도 그게 어디에요. 이거의 또 장점은 뭐냐하면 lock_free 알고리즘은 correct하다. 증명하는 게 너무 힘든데 증명이 너무 쉬워요. 돌아가기만 하면 증명이 된 거에요. 싱글쓰레드로 잘 돌아가는 원래 알고리즘이고 쪽났을 때 얘가 알아서 다 해주니까 증명이 무지 쉬워요. 성능보다는 그게 더 장점이에요. 오버헤드가 있죠? 그래서 아까 sum+2= 이 lock을 건 것보다 느려요. 왜? push한 다음에 다시 pop을 해야 하니까 롤백. 그리고 Intel이 뒤통수를 쳤어요. 통수를 쳤는데, 하스웰이라고 다 되는 건 아니에요. 되는 CPU 있고 안 되는 CPU 있어요. 그래서 Intel 홈페이지에 가서 되는 CPU 안 되는 CPU 잘 가려서 사셔야 되요. 비싸다고 되는 거 아니에요. 비싼 게 오히려 안되는 경우도 있어요. Intel 홈페이지 잘 참조하시고. 그래서 lock_free 프로그램 안 쓰고 다 이걸로 갈까 했는데, 아직도 lock_free 프로그램은 유효해요. Transactional Memory하더라도 lock_free 기법을 사용하셔야 되고 모든 경우에 다 되는 게 아니고. 그래서 미래는 이게 다인가? 그렇지는 않고 얘도 한계라고 보고 있어요. 서버는 왔죠? 옥타 코어 4개 꽂으면 64코어 나와요? 하이퍼쓰레드까지 해서. 그러면 어떻게 해야 되느냐? 왜 쓰레드간에 충돌이 생기느냐? C를 쓰기 때문이고, C는 왜? 공유 메모리, 변수 공유하고 사이드 이펙트 일어나니까 해결책은 C 안 쓰면 되요. 뭘 쓰냐? 이거 쓰면 되요. 하스켈, Earlang, Go, Rust 같은 거 쓰면 되요. Easrlang 쓰고 계신 분? 많이 쓰고 있어요. 여러 회사에서. 얘내들 Earlang하니까 좋아요. 제 친군데 14000 라인 Earlang 서버 만드니까 정말 잘 돌아가요. 많이 쓰고 있으니까. 왜 많이 안 쓰는가? 어려워서. 피보나치 함수 구하는 거, quicksort. 무슨 얘기인지 헷갈리는데 개념 자체가 어렵고 한번 배우면 쉬운데 진입장벽 넘기가 힘들어요. 정리를 하죠. Lock_free는 뭔가? 어떤 조건을 만족해야 되고, 어떻게 구현되고, 왜 어려운가? 왜 써야 되는가? 말씀을 드렸고 멀티쓰레드 프로그래밍의 미래. Transactional Memory. 여러분에게 닥쳐올 미래이고 새로운 언어? 5년후에 닥쳐올 미래에요. 저만 그렇게 생각하는 게 아니라 다들 이렇게 생각하고 있어요. 다음 준비를 하셔야 되고 다음에는 아마 이런 거 하게 되지 않을까? 생각을 하고 있습니다. 계속 바뀌니까 뭐가 될지 모르고. 여기 가시면 올려놨으니까 지금 한 거 보시면 되고. 이해 안 가시는 거 있으면 여기다 메일 주시면 대답을 해드리도록 하겠습니다. 공부를 하시겠다. 이 책보세요. 굉장히 잘 나와있으니까. 여기까지 하고 질문응답 받도록 하겠습니다. 
Spin lock. Spin lock은 broking이에요. 다른 애가 lock을 줄 때까지 돌아가야 되죠? 그러니까 broking이에요. 다른 애가 lock을 갖고 멈춰버리면 다른 쓰레드 다 멈춰요. Non broking은 그렇지 않아요. 루프를 돌긴 하지만 다른 쓰레드가 ‘나 더 이상 실행 못해.’ 하면 ‘그래? 내가 실행하지.’ 하고 실행이 되요. 그 차이가 있고요.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
