[Clean Code] 13장 동시성(Concurrency)

  단일 스레드는 콜 스택을 살펴보면 프로그램 상태가 바로 드러난다. 반면 멀티 스레드는 구조적인 관점에서 보면 하나의 루프가 아니라 작은 프로그램 여러 개가 돌고 있는 것으로 보인다. 시스템을 이해하기가 쉽고 문제를 분리하기도 쉽다.

 

- 동시성이 필요한 이유?

  : 처리 속도의 향상

 

- 난관  

: 동시성은 복잡하다.

: 동시성 버그는 재현하기 어렵다. 

 

- 동시성 방어 원칙

  : 동시성 코드는 다른 코드와 분리해야 한다.

  : 자료를 캡슐화하고 공유 자료(critical section)를 최대한 줄여야 한다.

  : 공유 객체를 복사해 읽기 전용으로 사용.

  : 스레드는 가능한 독립적으로 구현. (각 스레드는 클라이언트 요청 하나를 처리한다. 데이터는 로컬 변수에 저장. 다른 스레드와 동기화할 필요 없으므로 하나의 프로세스처럼 돌아감)

  

- 라이브러리 이해

  : 언어가 제공하는 클래스를 검토.

 

- 실행 모델 이해

  : Bound Resource(한정된 자원) - 멀티 스레드 환경에서 사용하는 자원으로 크기나 숫자가 제한적(DB 연결, 길이가 일정한 읽기/쓰기 버퍼)

  : Mutual Exclusion(상호 배제) - 한 번에 한 스레드만 공유 자원을 사용할 수 있는 경우

  : Starvation(기아) - 스레드가 오랫동안 혹은 영원히 자원을 기다림(자원 우선순위)

  : Deadlock(데드락) - 서로 다른 스레드가 각각 필요한 자원을 점유하고 있어서 서로 끝나기를 기다리는 상태

  : Livelock(라이브락) - 각 스레드가 서로 락 거는 것을 방해

 

- 동기화하는 메서드 사이에 존재하는 의존성 이해

  : 공유 객체 하나에는 메소드를 하나만 사용

 

- 동기화하는 부분 작게

  : 임계 영역(critical section) 수를 최대한 줄이고 크기도 작게

 

- 올바른 종료 코드를 구현하기 어렵다.

  : 어렵다. 기존의 알고리즘을 검토하라.

 

- 멀티 스레드 코드 테스트

  : 문제를 노출하는 테스트 케이스를 작성하자.

  : 프로그램 설정, 시스템 설정을 바꿔가며 자주 테스트

  : 한번이라도 실패하면 문제가 있다. 끝까지 추노 하라.

  : 말이 안 되는 실패는 잠정적인 스레드 문제로 취급

  : 여러 플랫폼에서 돌려 볼 것