boost unordered map insert 와 find
글쓴이: plrmsu / 작성시간: 화, 2016/03/08 - 10:03오전
안녕하세요
boost unordered map을 사용중 문의가 있어 이렇게 글을 쓰게 되었습니다.
멀티 쓰레드 환경에서 공유 자원으로 unoredered map 사용하고 있습니다.
delete는 사용하지 않고 find 와 insert만 사용하고 있는데
성능상 이슈로 lock을 걸지 않고 사용하고 있습니다.
lock을 걸지 않을 경우 find도중 insert를 하게 되면 iterator가 꼬여
find에서 error 발생할 수 있다는 생각을 했는데,
거꾸로 insert에서 core를 떨구면 프로세스가 죽는 현상이 생기고 있습니다.
segment fault에 대한 signal 핸들링은 하지 않고 있습니다.
혹시 이런경험 있으신가여?
Forums:
ㅎㄷㄷ
동시에 여러 개의 쓰레드가 접근할 수 있는 container를 락을 안 걸고 쓰는 건 그냥 잘못된 코드입니다. 어디서 언제 어떻게 죽어도 이상하지 않습니다. (여기서 "어디서"는 find, insert 정도가 아니라, 메모리가 깨지면 문자 그대로 프로그램 아무 데서나 다 죽을 수 있다는 말입니다. 확률적으로 그 container를 쓰는 곳에서 죽을 확률이 높을 뿐이죠.)
답변 감사 합니다. 원칙은 lock을 무조건 걸어야
답변 감사 합니다. 원칙은 lock을 무조건 걸어야 되는데, 제가 일하는 분야에서는 성능에 워낙 민감해서
lock를 사용하지 않는 경우도 종종 있어문의를 드렸는데, 제 질문이 잘못 된것 같습니다.
좋은하루 보내세여^^
...
성능 때문에 lock을 안 걸어도 되는 경우는 매우 제한적입니다. 예를 들어 이벤트의 갯수를 세는 변수가 있어서
이런 경우라면 락을 걸지 않아서 생길 수 있는 최악의 경우라고 해봤자 변수의 값이 잘못 들어가는 것이니 이 변수값을 "대략의 카운트"로 생각하고 가끔씩 엉뚱한 값이 나와도 괜찮다고 한다면 이렇게 쓸 수 있습니다.
하지만 이건 특수한 경우고, 일반적으로 "동시에 여러 쓰레드가 접근하는 상황"을 간주하지 않은 코드에서 동시에 여러 쓰레드가 접근하면 그냥 무조건 버그라고 생각하시는 편이 좋습니다. 특히 요즘은 컴파일러와 CPU가 쓸데없이(?) 좋아져서, 코드에서 변수 a와 b를 순서대로 사용해도 컴파일러가 순서를 바꿔 놓을 수 있고, 컴파일러가 안 그래도 CPU가 자기 맘대로 순서를 바꿔서 실행할 수 있습니다.
성능에 민감한 경우라면 shared_mutex나
성능에 민감한 경우라면 shared_mutex나 upgrade_mutex를 사용하시는걸 추천드립니다.
감사합니다.^^ 수고하세요
감사합니다.^^ 수고하세요
감사합니다.^^ 수고하세요
감사합니다.^^ 수고하세요
댓글 달기