초벌 번역한 것으로 세세하게 단어와 문맥을 다듬은 글이 아닙니다.;;;;
대략적인 내용 파악을 위한 자료로만 활용해 주세요.^^;;
[원문]
What Every Dev Must Know About Multithreaded Apps
이 글에서 다룰 주제들
- 멀티쓰레딩과 공유 메모리 쓰레딩 모델
- 경함 그리고 동시 접근이 불변식을 어떻게 깨뜨리는지
- 경함에 대한 표준적인 해결법인 잠금
- 잠금이 필요할 때
- 잠금의 사용법과 이에 대한 비용을 이해하기
- 쓰레드와 메모리
- 경합(Races)
- 락(Lock)
- 락 프로퍼티 사용하기
- 락은 몇 개나?
- 읽기에서 락 사용하기
- 락을 사용한 보호를 필요로하는 메모리
- methodical lock
- 데드락
- 락의 비용
- 동기화에 관해 훑어보기
- 결론
대부분에서 보여지는 멀티쓰레드 통신 모델은 '공유 메모리 모델(shared memory model)'이라고 부른다. 이 모델에서의 모든 쓰레드는 그림 3에서 볼수 있듯이 같은 공유 메모리 풀에 접근한다.이 모델은 멀티쓰레드 프로그래밍을 순차적인 프로그래밍 방식과 같은 방법으로 할 수 있다는 이점이 있다. 그러나 이 이점이 또한 가장 큰 문제이기도 하다. 이 메모리는 쓰레드안에서 사용하는 로컬 메모리(로컬로 선언된 변수 같은 것들)와 다른 쓰레드와 통신하기 위해 사용하는 메모리(전역 변수나 힙 메모리 같은것)을 구별하지 않는다. 잠재적으로 공유된 메모리는 쓰레드 로컬 메모리보다 훨씬 더 신중하게 다뤄야 하기 때문에 실수가 발생하기 쉽상이다. 경합(races) 프로세스들이 요청을 하고, 이 요청이 완료될 때마다 값이 증가하는 전역 카운터 totalRequests를 가지고 있는 프로그램이 있다고 치자. 보다시피, 이를 수행하는 코드는 순차적인 프로그램에서는 명백하다. totalRequests = totalRequests + 1
하지만, 요청과 카운터의 갱신을 처리하는 여러 개의 쓰레드를 가진 프로그램에서는 문제가 생긴다. 컴파일러는 다음과 같은 기계어 코드로 (카운터의)증가 코드를 생성할 것이다. MOV EAX, [totalRequests] // load memory for totalRequests into register INC EAX // update register MOV [totalRequests], EAX // store updated value back to memory
두 개의 쓰레드가 이 코드를 동시에 실행하는 상황을 가정해 보자. 그림 4에서 볼 수 있듯이, totalRequests의 같은 값을 로딩하여, 증가시킨 후, 다시 저장시킬 것이다. 이 일련의 동작이 끝나는 시점에서 두 쓰레드는 요청을 처리했지만, totalRequests의 값은 이 전과 비교했을 때 1만 증가했을 뿐이다(역주: 두 개 처리 했으니가 2가 증가하는 것이 맞다). 확실히 이것은 우리가 원한 결과가 아니다. 이런 버그를 경합이라고 부르는데, 두 쓰레드 사이의 나쁜 타이밍 문제로 발생하는 것이다. 그림 4 경합의 경우 들여다보기 
이 예는 자명해 보이지만, 일반적인 문제는 실생활에서 벌어지는 경합만큼이나 복잡한 것이다. 여기에 경함이 발생할 수 있는 네 가지 조건을 나열해 보겠다.
첫 번째 조건은 하나 이상의 쓰레드가 접근할 수 있는 메모리가 존재할 때 이다. 보통 이런 메모리는 전역/스태틱 변수이거나 이런 변수로부터 접근할 수 있는 힙 메모리이다.
두 번째 조건은 이런 공유 메모리가 프로그램이 올바르게 작동하기 위해 사용되는 속성일 경우이다. totalRequests가 이런 속성으로 어떤 쓰레드가 실행되고, 값이 증가하는 어떤 경우이던 전체 횟수를 정확히 나타내야 한다. 정확한 갱신을 위해서는 갱신전에 유효성을 확인(totalRequests가 정확한 값을 가져야 하기 때문에)할 칠요가 있다.
세 번째 조건은 그 속성이 실제 갱신되는 중에 점유되지 않는 경우이다. 이 경우에는 totalRequests를 불러와서 저장하는 동안에 불변성을 만족하지 않는다.
네 번째이자 마지막인 경합의 조건은 다른 쓰레드가 불변성이 깨졌을 때 접근한 후, 이로 인해 오동작이 발생하는 경우이다.
-- 다음에 계속 --
