본문 바로가기

2015/0417

Modern Effective C++ item 25 : std::move / std::forward 를 적재적소에 사용하자. std::move / std::forward 를 적재적소에 사용하자.item 23,24에서 이야기한 것처럼, std::move는 인자를 무조건적으로 rvalue reference로 캐스팅하고, std::forward는 인자가 rvalue인지 체크해서 조건부로 rvalue reference로 변경한다. 여기서 주의해야할 사항이 있다. universial Reference에는 std::move를 사용해선 안되고, rvalue reference에는 std::forward를 사용해선 안된다. 전자는 정말 위험하다.universial Reference에 std::move를 쓰지말자.class Widget{ public: template void setName(T&& newName) //T&&는 universial.. 2015. 4. 28.
Lock Free Lock Free지금까지 자원 Lock의 필요성과 여러가지 Lock의 활용방식을 공부했다. 논리적 측면에서 Deadlock 이슈를 피해서 lock을 사용한다면, 문제없이 자원공유가 가능한 것처럼 보인다^^. 하지만 멀티 쓰레드 프로그래밍의 어려움은 여기서 부터 시작한다. 앞에서 조금씩 언급했지만, 무차별적인 Lock은 기아현상을 유발할 수 있다. 사용자가 느끼기에 중요한 쓰레드가 상대적으로 별로 중요하지 않은 쓰레드에 밀려서 자원획득을 못하고 있을 가능성도 있다. 프로그래머가 프로그래밍을 잘하면 해결할 수 있는 문제라고 생각할지도 모른다.그럼 성능이슈는 어떤가? CRITICAL_SECTION을 사용하는 Mutex역시 시스템 자원이다. Lock을 거는것 하나하나가 시스템 자원요청이라고 생각하면 락을 거는 .. 2015. 4. 28.
Thread Local Storage Thread Local Storage멀티 쓰레드 프로그래밍을 하다보면 불편한게 있다. 쓰레드별 고유한 전역변수(또는 정적변수) 사용하기가 어렵다는 것. 쓰레드를 그냥 만들면 쓰레드에게 주어진 혼자만의 공간은 지역적인 stack영역 뿐이다. 일반적인 전역변수는 다 공유되는 data영역에 저장된다. 그렇다고 힙에 만들어도 private 힙이 아닌 이상 역시나 공유되는 공간이다. 그렇다고 int하나를 위해서 private 힙을 만드는 것은 말이 안된다. 스레드가 특정 함수만을 반복적으로 수행하면 별로 필요없다고 생각할 수 도 있는데, 막상 없으면 아쉽고 쓸려면 없다. Thread Local Storage(이하 TLS)는 쉽게(?) 쓰레드별 저장공간을 마련해주는 방법이다.TLS의 원리https://msdn.mi.. 2015. 4. 26.
read-write lock Reader-Writer LockRead와 Write는 자원을 사용하는 일반적인 방법이다. 기존의 Mutex 방식 Lock은 같은 자원에 대해서 Read이건 Write이건 배타적인 사용방식을 고수했다. 자원을 Read하고 있으면 다른 스레드가 그 자원에 Write작업을 수행할 수 없고, 그 반대의 경우도 마찬가지이0다. 누군가 새로 메모리에 새로운 값을 입력하는 도중에 그 값을 읽으면 내용의 일관성이 깨지기 때문에 일견 타당할 수 있다. 하지만 Read와 Read의 관계에서 다시 한번 생각해보자. 단순 읽기 동작은 내용의 일관성을 해치지 않기 때문에 서로 동시에 같은 내용을 읽어도 동기화 문제가 발생하지 않는다. Read끼리는 락을 하지 않는다면, 좀더 자원을 효율적으로 사용할 수 있지 않을까? 이런 아.. 2015. 4. 26.