Lock을 잡는 scope는 최소화 해야 하는 것은 잘 알고 있을 것이다.
swap을 활용하면 더 좋다는 것에 대해서 이야기 해보려고 한다.
개발을 하다보면 map을 만들어 놓고 객체를 등록하고, 찾고, 제거하는 일을 많이 하게 된다.
예를 들어 다음과 같은 Manager class를 만들어 사용한다고 하자
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
class Manager { private: std::map< int, std::unique_ptr<Foo> > _cont; public: bool Register(int id, std::unique_ptr<Foo>& ptr) { return _cont.insert({ id, std::move(ptr) }).second; } bool Remove(int id) { return (_cont.erase(id) > 0); } }; |
만약 Manager가 멀티쓰레드 환경에서 thread safe해져야 한다면,
lock free container를 도입하거나,
lock을 사용 해야 한다.
만약 lock을 사용한다면 …
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
class Manager { private: std::map< int, std::shared_ptr<Foo> > _cont; std::mutex _lock; public: bool Register(int id, std::shared_ptr<Foo>& ptr) { std::lock_guard<std::mutex> guard(_lock); return _cont.insert({ id, std::move(ptr) }).second; } bool Remove(int id) { std::lock_guard<std::mutex> guard(_lock); return (_cont.erase(id) > 0); } }; |
보통 이렇게 할 것이다.
하지만, Remove함수에서 좀 더 최적화를 할 수 있는 여지가 남아있는데…
Remove 함수에서 lock을 잡은 후에 일어나는 일을 먼저 살펴 보면
1. _cont에서 id에 해당하는 node를 찾아서 지운다.
2. Foo의 소멸자가 호출되고, 메모리 해제가 된다.
1번의 과정은 정확히 lock이 필요하지만, 2번의 과정은 lock이 과정이 없어도 된다.
(여기서 Manager class의 lock은 map을 보호하는 것이지 class Foo 를 보호하는 것이 아님)
이 문제는 다음과 같이 swap을 활용하면 해결 할 수 있다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
bool Remove2(int id) { std::shared_ptr<Foo> ptr; { std::lock_guard<std::mutex> guard(_lock); auto itr = _cont.find(id); if (itr == _cont.end()) { return false; } ptr.swap(itr->second); _cont.erase(itr); } return true; } |
뭔가 코드의 줄 수는 늘어나서 좋지 않아보이지만, 분명히 최적화는 되었다.
만약 Clear함수를 만든다면….
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
void Clear() { std::lock_guard<std::mutex> guard(_lock); _cont.clear(); } void Clear2() { decltype(_cont) temp; { std::lock_guard<std::mutex> guard(_lock); _cont.swap(temp); } } |
Clear() 보다 Clear2()가 코드 줄수는 조금 더 길지만, 최적화 되었다.