ZepehWAVE ZepehWAVE

클래스 내에서 어떤 객체를 반환하고 싶다. 하지만 반환되는 과정의 오버헤드가 두려울 수 있다. 1234std::string get_name() const{ return std::string(my_name);} 일단 저 구문을 보면 이렇게 될거라 생각할 수 있다. 3에서 임시 객체가 만들어지고, 그걸 반환하면서 복사 생성자가 또 호출될 것이다!과거에는 그랬다. 하지만 근래의 컴파일러는 다음처럼 내용을 바꿔버린다. 1234void get_name(std::string& dest) const{ new(&dest)std::string{my_name};} 이를 반환값 최적화(Return Value Optimization)라고 하며 이것에 의해 다음과 같은 구문들은 사실상 같은 것일 수도 있다. std::array..

데드락과 라이브락 데드락(Deadlock) 데드락은 스레드들이 서로 상대방이 가진 자원을 기다리느라 전혀 진도를 나가지 못하는 상황이다. 두 개의 뮤텍스 락 A, B를 모두 획득하려는 두 개의 스레드를 예를 들어보자.스레드0이 락A를 스레드1이 락B를 각각 획득한 상태라면 스레드0은 B를 확보할 수가 없어 작업 진행을 할 수 없고,스레드1은 락A를 확보할 수 없어 작업을 진행하지 못한다. Thread0 void update(){ 획득(A) 획득(B) // 스레드0은 여기서 무한 대기 어떤작업() 해제(B) 해제(A)} Thread1 void update(){ 획득(B) 획득(A) // 스레드1은 여기서 무한 대기 어떤작업() 해제(A) 해제(B)} 라이브락(Livelock) 라이브락은 두 스레드가 락의 ..

데이터 레이스는 다중 스레드 프로그래밍을 할 때 범하기 쉬운 오류 중 하나이다. 데이터 레이스는 멀티 스레드를 이용하는 환경에서, 같은 데이터를 이용하고 다른 스레드에서 그것을 업데이트 할 때 발생한다. 아래와 같은 코드가 있다. // a를 읽어 %o1에 저장 // %o1에 4를 더함 // %o1를 a에 저장 void update_int( int* data ) { *a = *a + 4; } 이 코드가 멀티 스레드로 구동되고, 두 스레드에서 동시에 같은 데이터의 값을 증가시키려 할 때는 이런 상황이 발생할 수 있다. int a = 10; // a는 여러 쓰레드에서 공유가 되고있는 변수이다. Thread[0] a를 읽어 %o1에 저장 %o1에 4를 더함 %o1의 값을 a에 저장 Thread[1] a를 읽어 ..

뮤텍스(Mutex)와 크리티컬 리전/섹션(Critical Region/Section) 가장 단순한 동기화 장치는 상호 배타적인 잠금 매커니즘인 뮤텍스이다.뮤텍스를 사용하면 락을 획득한 스레드만이 그 구역에 접근이 가능하므로, 특정 데이터 구조를 뮤텍스 락으로 둘러싸면 한 시점에 한 스레드만 접근하게 만들 수 있다. int counter = 0; void inc(){ acquire(mutex); ++counter; release(mutex); } void dec() { acquire(mutex); --counter; release(mutex); }여러 개의 스레드가 같은 뮤텍스 락을 동시에 얻으려고 시도해도 한 스레드만 락을 얻고, 다른 스레드들은 대기하게 된다. 락을 얻기 위해 대기하는 상황을 Conte..

원자적 조작과 락-프리 코드(Atomic operation & Lock-Free code) 동기화 장치를 사용하면 높은 오버헤드가 따른다.어떤 경우에는 원자적 조작을 이용하거나, 락 프리 형태로 동등한 작업을 구현하는 것이 오버헤드를 피하는 한 방법이 될 수 있다.원자적 조작이 수행되는 중간에는 다른 스레드가 끼어들 여지가 없고, 중간 결과를 시스템에서 엿보는 것도 불가능하다.왜냐? 원자적(Atomic)이므로 쪼개질 수 없기 때문이다. 일반적인 변수인 A를 A+1로 바꾸는 작업은 아주 단순해보이지만 다음과 같은 단계를 거친다.A를 로딩해 %o1에 저장%o1의 값을 증가시킴%o1를 A에 저장이 3단계의 명령 수행을 진행하는데에는 각 단계마다 다른 스레드에서 간섭할 수도 있고, 변수가 위치한 메모리에 값을 ..

배리어(Barrier) 특정 작업을 시작하기 전에, 다른 스레드가 모두 완료되어야만 하는 때가 있을 수 있다. 이럴때 배리어를 이용하면 다른 스레드가 작업을 완료할 때까지 대기할 수 있다. 전형적인 사용 시기는 서로 다른 두 코드가 종속성을 가질 때다. 아래 코드에서 변수 total은 행렬의 각 항목에 값이 모두 설정되어야만 계산될 수 있다. 배리어를 이용하면 변수 total을 계산하기 전에 행렬에 값을 설정하는 모든 스레드가 완료하는 것을 보장한다. 배리어를 이용한 순서 보증 compute_values_held_in_mat();barrier(); // 배리어total = calc_value_from_mat();

리더즈-라이터 락(Readers-Writer Lock) 데이터 레이스는 공유 데이터를 변경하려 할 때만 발생한다.여러 개의 스레드가 공유 데이터에 대해 읽기 작업만을 한다면, 락으로 데이터를 보호할 필요가 없다.대부분 작업이 읽기로 이루어져있지만 가끔씩 쓰기 작업을 수행해야 할 때 리더즈-라이터 락을 사용하며,이 락은 읽기 락을 모두 해제하기 전에는 쓰기 락을 획득할 수 없는 락이다.

세마포어(Semaphore) 세마포어는 카운터다. 증가/감소가 있을 수 있다.특정 리소스의 개수가 한정되어 있고, 여러 스레드에서 그 자원을 이용하려 할 때 사용하곤 한다. 세마포어는 열차 선로를 운영할때 기관사에게 해당 선로로의 진입 가능 여부를 알려주던 깃발을 뜻하는 용어로,세마포어를 획득하는 것을 wait, down, acquire이라 하고 해제하는 것을 post, up, signal, release라고 한다. 세마포어로 관리되는 리소스스를 다른 스레드가 접근하려 할때, 가용 가능한 리소스가 없다면 리소스를 요청한 스레드는 가용 가능하질 때까지 블로킹 된다.