Topic 34 공유 상태는 틀린 상태
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
공유 상태는 틀린 상태다.
p.249
공유 상태가 필연적인 경우가 분명 존재하기에 버그의 가능성도 분명 존재한다.
비-원자적 갱신
세마포어 및 다른 상호 배제 방법
세마포어 semaphore 는 단순히 한 번에 한 사람만이 가질 수 있는 무언가다.
…
진열장의 내용물을 바꾸고 싶은 사람은 세마포어를 소유하고 있을 때만 바꿀 수 있다는 규칙을 도입하는 것이다.
p.251
운영체제 시간에 배웠던 개념이 등장했다. 결국 파고 들어가보면 쓰이는 기법은 공통적인 부분이 많아 공유되는 것 같기도 하다.
리소스를 트랜잭션으로 관리하라
제어를 중앙으로 집중시키자. 그러려면 API 를 바꿔서 종업원이 하나의 호출로 파이 조각 수를 확인함과 동시에 파이 조각을 가져가도록 만들어야 한다.
p.252
책임을 분산시키기 보다는 한 곳에서 처리하는 것이 프로그래밍 관점에서 버그를 줄일 수 있는 방법 같다. 주어진 책임을 정확하게 맡아 처리할 때 버그가 발생할 확률이 줄어든다. 대체로 책임을 명확하게 만들지 못해 코드의 품질이 떨어지는 것 같다.
하지만 이 메서드 자체도 여러 개의 스레드에서 동시에 호출될 수 있으므로 여전히 세마포어로 보호해야 한다.
p.253
세마포어를 적용해도 메서드 안에 메서드가 있을 경우 내부 메서드에서 세마포어 처리를 하지 않았을 경우 동시성 문제가 발생할 수 있다. 확실히 버그의 가능성은 언제나 도사리고 있는 것 같다. 그렇기에 테스트 케이스가 촘촘하고 여러 시나리오로 존재해서 미리 버그를 찾고 수정하는 것이 중요하겠다.
예외를 발생시키면 세마포어는 영영 잠금이 풀리지 않을 것이고, 이후로 진열장에 접근하면 하염없이 기다리게 될 것이다..
p.253
트랜잭션이 없는 갱신
불규칙한 실패는 동시성 문제인 경우가 많다.
p.257
동시성이 지원됨에 따라 퍼포먼스는 향상되었지만 골치 아픈 것도 향상된 것 같다. 고민하고 핸들링해야할 것이 그만큼 늘어났기 때문이다.
리소스를 공유하는 환경에서 동시성은 어렵다. 이 문제를 직접 풀려고 한다면 고난의 연속일 것이다.
p.258
뒤 2챕터에 걸쳐 동시성의 이득을 취할 수 있는 방법을 설명한다고 하는데 어떤 방법일지 기대된다.
Topic 34 느낌
Topic 34 에서는 불편함을 나열하고 뒤에 나올 내용을 통해 어떻게 해결할 수 있는지를 설명한다고 하는데 반신반의이기는 하다. 어떻게 동시성 문제를 풀 수 있을지 말이다.