인프런 커뮤니티 질문&답변
작성한 질문수
성능 테스트 결과
작성
·
42
·
수정됨
0
SList로 구현한 코드와 Lock을 걸며 큐에 pop push를 하는 코드의 실행시간을 스레드의 수와 일의 반복수(for문의 반복횟수)를 늘려서 시간을 측정해보았더니 Lock을 걸어 실행한 시간이 더 짧게 나오는데 둘다 어쨋든 CAS연산을 해주기 때문에 그런것일까요? 그렇다고 하면 굳이 LockFree로 구현하는 이유가 뭔지 궁금합니다
Lock을 쥔 스레드가 데드락이 되어 다른 스레드들도 통과를 못하는 경우가 있어서 그런건가요?
답변 2
1
상황에 따라 다른데요.
일감이 충분히 많은데 Read, Write 쓰레드가 1개씩 붙어 병합이 심할 경우,
Lock을 잡는 버전보다 LockFreeQueue가 꽤 이점을 보일 수 있긴 합니다.
왜냐하면 Lock은 무조건 동시 접근을 배타적으로 걸어야 하는 반면,
LFQ 버전에서는 Push와 Pop을 동시에 해도 (데이터가 충분히 많다는 가정 하에)
서로 영향을 주지 않아 실패를 하지 않기 때문이죠.
이론적으로는 그렇지만 사실 LockFree를 사용 안 해도
전혀 차이 안 나거나 오히려 성능이 더 좋은 경우가 대부분입니다.
0
안녕하세요, 인프런 AI 인턴입니다. kamdabin3님.
Lock-Free 구조와 Lock-Based 구조의 성능 비교와 관련하여 궁금한 점이 있으시군요.
먼저, Lock-Free 자료구조는 일반적으로 스레드의 경합(lock contention)이 심한 환경에서 성능이 좋아질 수 있지만, 모든 경우에 Lock-Based 구조보다 더 좋은 성능을 보장하는 것은 아닙니다. 특히, 스레드의 수가 적거나 경합이 적은 상황에서는 Lock-Free 구조의 복잡한 CAS(Compare-And-Swap) 연산이 오히려 오버헤드가 될 수 있습니다. 이런 상황에서는 Lock-Based 구현이 더 단순하고 효율적으로 작동할 수 있습니다.
하지만 Lock-Free 구조의 주요 장점은 데드락(deadlock)의 우려가 없고, 전반적으로 스케일링(scaling)이 더 잘된다는 점입니다. 즉, 스레드가 많아지거나 시스템이 커지더라도 성능이 급격히 저하되지 않는 장점이 있습니다.
따라서, Lock-Free를 구현하는 이유는 특정 환경에서 일관된 성능을 유지하고자 할 때, 특히 경합이 많은 환경에서 성능 개선과 안정성을 기대할 수 있기 때문입니다.
관련된 주제의 링크를 몇 가지 추천드립니다:
1. 메모리풀, 오브젝트풀 강의 관련 궁금한 점이 있습니다.
2. Lock-Based Queue 병목현상 질문 드립니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.