서버 / 클라이언트 쪽에서의 동시성(concurrency)의 차이

라는 글이 Sutter’s Mill에 올라왔음.

개략적인 내용은 서버 응용 — 특히 DBMS와 연동되는 다수의 요청과 그에 대한 transaction을 사용하는 구조 — 에서는 동시성을 위해서 하는 일이,

• 대다수의 작업이 transaction 기반
• 동시성 자체가 DBMS 단에서 처리됨
• DBMS 자체의 동시성 처리는 많은 경우 row lock -> page lock or index lock -> table lock 같은 잘 알려진 알고리즘으로 해결됨

과 같은 이유로 이미 풀려있는 문제에 가깝다라는 것. 그리고 서버용 동시성 응용도 rocket science ((복잡하고 어렵고 고도의 기술/지능이 요구되는 분야를 가리키는 말. 비슷한 방식으로 ‘brain surgery’ 같은 것도 있음. from Wikipedia)) 지만, 충분한 수의 전문가 집단이 존재하고, 성공적인 방식으로 여러 번 완성시킬 수 있다는 것 — 그러니까 풀린 문제랄까.

반대로 요즘 issue가 되고 있는 클라이언트(=일반 응용프로그램) 에서의 동시성이란 것은 많이 다르다라는게 글의 요지.

거의 위에서 설명된 것과는 정반대로,

• 처리해야할 일 자체가 근본적으로 동시성에 적합하지 않아서 구조를 해집고 다녀야하고
• 프로그램에서 사용될 객체들이 그다지 동시성에 적합하지 않아서 (cf. DBMS)
• 명시적인 lock 기반이라 이런 저런 문제에 쉽게 노출된다는 것

그래서 현재의 상태는 V2 로켓을 만들던 시절의 로켓과학(rocket science)이고, 이를 좀 벗어나서 OpenMP나 intel TBB같이 좀 더 나은 상태를 거치고 있고, Task Parallel Library나 PLINQ 같은 훨씬 근대적인 라이브러리들이 생겨난다는 것.

+ 10월의 C++ Standard Comitee 쪽에서는 TPL이나 PLINQ 수준의 C++ native support에 관한 얘기가 있을 것이라함

글에서 설명된 것처럼 transaction-like 구조가 C++에 추가되거나 할지도 모르겠음.

여튼 간단한 결론: 잘 정규화되지 않는 클라이언트 쪽의 동시성(concurrent) 프로그래밍은 쉽지 않다.

개인적인 결론: 아예 Erlang을 쓰는 것은 어떻게 보면 무리 같고 (통신을 정의하는게 쉽지 않아 보임), 앗싸리 PLINQ 수준의 어느 정도 일반적인 동시성 구문이 생겨나야할 것 같다랄까.