뭐 그냥 주절주절...

보기 싫은 사람은 백스페이스요


처음엔 막 lock-free니 wait-free니 하는거 존나 팠거든

근데 시발 이거 코딩하기 존나 어렵지...

논문을 봐도 이게 왜 올바르게 돌아가는지 이해하는데 2~3일은 족히 잡아 먹고

어떻게 올바르게 돌아가는 코드를 잘 짰다고 해도 별로 유연하지 못하고

게다가 난 C++이라 ABA에서 벗어 날 수 없지

그러니 동작을 좀 바꾸고 싶어도 코드를 건드릴 엄두가 안 나고...


그래서 나중엔 어지간하면 그냥 lock만 가지고 코딩하게 되더라...

솔까말 쿼드 수준에서는 코드가 수행되는 시간의 95% 이상은 contention 안 일어나거든

나머지 5%도 일부 코드에만 집중되어 있으니 그 쪽만 손대는게 맞지


근데 그런 류의 코드를 보면 대부분 고도로 일반화된 라이브러리나 자료 구조고
 
그런건 보통 남들이 이미 존나 잘 만들어 놓은 코드가 있다는 거지 ㅋㅋㅋ


메모리 할당에서 좀 확장성 문제가 있어서 공부할 겸 lock-free로 만들어보자 했거든

근데 lock-free 메모리 할당자 어떻게 만들어 놨더니 LFH보다 구리고 ㅋㅋㅋ

아 참고로 LFH도 기본적으로는 lock-free고, vista부터는 기본 할당자다

당연히 TBB 메모리 할당자 같은 거하고는 order of magnitude 수준으로 퍼포먼스 차이가 나고 ㅋㅋㅋ


결국에는 그냥 immutable한 객체 위주로 쓰고 shared data는 최대한 줄이고

이런 기본 원칙을 지키면서 하는게 제일 생산성 높고 퍼포먼스도 필요한 만큼은 나오더라

존나 퍼포먼스가 필요한 경우는 남들이 만들어 놓은거 가져다 쓰는게 제일 낫고

아니면 필요한 경우 actor나 CSP 기반의 프레임워크 같은거 간단하게 만들어 써도 괜찮고...

사실 Concurrency Runtime이나 TBB가 존나 우월해서 다른 거 쓸 이유가 있나 싶기도 함.


뭐 HTM이 구현되면 만사 해결이나 다름 없는데 ㅋㅋㅋ

이건 10년 내로는 나올 가망이 안 보이니


아 시발 근데 이거 진짜 답 없긴 하네...
 
뭘 해도 병행성 고려하기 시작하면 문제가 5배는 복잡해지니

병행성때문에 문제가 꼬이면 형들은 어떻게 대처함?