2009년 10월 02일
lock-free 회의론
저도 이전에 lock-free에 대해 관심이 많이 생겨서 이것 저것 많이 알아보고 구현도 해본적이 있습니다만 현재는 회의적인 입장입니다. 이유는 2가지 입니다.
lock-free 알고리즘의 하나인 SpinBuffer의 경우 두가지 제약이 있습니다. 하나는 소비자 스레드와 생산자 스레드가 각각 하나씩이어야 한다는 것이고 다른 하나는 두 스레드가 블럭되지 않고 SpinBuffer의 생산, 소비 함수를 주기적으로 호출을 해야 한다는 점입니다. 이 두 조건을 모두 만족하는 상황에서만 SpinBuffer를 사용해야 합니다. 그외에 대부분의 lock-free 알고리즘은 이러한 자기만의 제약사항이 있습니다. 거기에 공통적인 문제점인 ABA 문제도 있죠. 이런 문제점을 잘 이해하고 사용하지 않으면 큰 낭패를 볼 수 있습니다.
노력대 성능비
이렇게 제약사항을 모두 충족시키며 적용을 했음에도 불구하고 lock-free 알고리즘을 적용하여 향상되는 성능은 미미한 편이었습니다. 그보다는 busy wait나 context switching을 줄임으로서 얻는 성능의 향상이 더 컸습니다.
Proactor 패턴
Half-Sync/Half-Async 패턴
바람직한 Producer-Consumer 모델
lock-free 알고리즘을 이해하고 구현하는데 시간을 들이는 것보다는 기존의 concurrent 패턴을 잘 이해하고, 그안에서 성능을 향상시키는게 가격대 성능비(?)로 낫다고 판단했습니다. 그래서 요즘은 concurrent 패턴들을 조금 더이상적으로 구현하는데 신경을 쓰고 있습니다. 성급하게 응용을 하기 보다는 원저자의 의도에 가깝게 FM대로 구현을 하는 것이지요.
- 사용하는데 제약이 너무 많음
- 들인 노력에 비해 향상되는 성능이 크지 않음
lock-free 알고리즘의 하나인 SpinBuffer의 경우 두가지 제약이 있습니다. 하나는 소비자 스레드와 생산자 스레드가 각각 하나씩이어야 한다는 것이고 다른 하나는 두 스레드가 블럭되지 않고 SpinBuffer의 생산, 소비 함수를 주기적으로 호출을 해야 한다는 점입니다. 이 두 조건을 모두 만족하는 상황에서만 SpinBuffer를 사용해야 합니다. 그외에 대부분의 lock-free 알고리즘은 이러한 자기만의 제약사항이 있습니다. 거기에 공통적인 문제점인 ABA 문제도 있죠. 이런 문제점을 잘 이해하고 사용하지 않으면 큰 낭패를 볼 수 있습니다.
노력대 성능비
이렇게 제약사항을 모두 충족시키며 적용을 했음에도 불구하고 lock-free 알고리즘을 적용하여 향상되는 성능은 미미한 편이었습니다. 그보다는 busy wait나 context switching을 줄임으로서 얻는 성능의 향상이 더 컸습니다.
Proactor 패턴
Half-Sync/Half-Async 패턴
바람직한 Producer-Consumer 모델
lock-free 알고리즘을 이해하고 구현하는데 시간을 들이는 것보다는 기존의 concurrent 패턴을 잘 이해하고, 그안에서 성능을 향상시키는게 가격대 성능비(?)로 낫다고 판단했습니다. 그래서 요즘은 concurrent 패턴들을 조금 더이상적으로 구현하는데 신경을 쓰고 있습니다. 성급하게 응용을 하기 보다는 원저자의 의도에 가깝게 FM대로 구현을 하는 것이지요.
# by | 2009/10/02 05:54 | 기타 | 트랙백(1) | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 :
http://javawork.egloos.com/2439670 "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Sir Charles Antony Richard Hoare ;Donald Knuth가 한 말이 아니라는군요. ;(http://en.wikipedia.org/wiki/C.A......more