write에서 건 lock이 효과가 있으려면 read에서도 당연히 같은 lock을 검사해야죠...
write끼리만 충돌 안하면 되는것 아니냐 생각하신다면,
대부분의 경우 write 연산이 atomic하지 않기 때문에 read만 할때에도 lock이 필요합니다.
가시적인 예로, 탁구 점수판을 09에서 10으로 바꾸려면 19라는 중간 상태가 존재하겠죠. 저 값을 읽으면 안되니까...
위에 예로 들으신건 write일때의 예로 생각이 되며.. 조금 이해가 안되는게 write할때는 수정이 되기에 lock을 하는것으로 이해가 되는데.. read 할때의 이유는 무엇인가요?
생각해보니 read_lock이 존재하는거 보니 read할때도 동시접근성이 허용이 되지 않는것 같은데 맞나요?
만약 일반 어플단 프로세서에서도 동일메모리에 여러 쓰레드가 동시에 접근(read만)한다면 문제가 발생하게 되나요?
읽는도중에 쓰여질수 있지안을까요??
읽는도중에 쓰여질수 있지안을까요??
아뇨 해당 루틴에 write는 없습니다. 해당
아뇨 해당 루틴에 write는 없습니다.
해당 메모리의 값을 다른 메모리에 넣어주는 건 있어도 원래 메모리에 값을 변경 하는 부분은 전혀 없습니다.
질문자께서 본 디바이스 드라이버가 메모리 리딩만하고
질문자께서 본 디바이스 드라이버가 메모리 리딩만하고 라이팅은 안한다고 해서 메모리접근하는데 락 할필요가 없지안느냐는건 조급한 판단아닐까요??
락킹같은경우 다른 장치처럼 프로세스 사이에 강제성이랄까요? 이 없기때문에 메모리를 접근하는 프로세스는 읽기락이든 쓰기락이든을 해주는게 좋은걸로 알고있습니다. 예외상황을 미연에 방지하고자?
저도 내공이바닥이라 제 생각을 주저린거니 필터링해주시고 고수분답변을 기다려보세요ㅠ
...
해당 루틴에는 write가 없을지 몰라도, 다른 어딘가엔 분명 write가 있겠죠. (안 그러면 컴파일 타임 상수나 마찬가지니까...)
write에서 건 lock이 효과가 있으려면
write에서 건 lock이 효과가 있으려면 read에서도 당연히 같은 lock을 검사해야죠...
write끼리만 충돌 안하면 되는것 아니냐 생각하신다면,
대부분의 경우 write 연산이 atomic하지 않기 때문에 read만 할때에도 lock이 필요합니다.
가시적인 예로, 탁구 점수판을 09에서 10으로 바꾸려면 19라는 중간 상태가 존재하겠죠. 저 값을 읽으면 안되니까...
위에 예로 들으신건 write일때의 예로 생각이
위에 예로 들으신건 write일때의 예로 생각이 되며.. 조금 이해가 안되는게 write할때는 수정이 되기에 lock을 하는것으로 이해가 되는데.. read 할때의 이유는 무엇인가요?
생각해보니 read_lock이 존재하는거 보니 read할때도 동시접근성이 허용이 되지 않는것 같은데 맞나요?
만약 일반 어플단 프로세서에서도 동일메모리에 여러 쓰레드가 동시에 접근(read만)한다면 문제가 발생하게 되나요?
read만 수행된다면 lock이 필요하지
read만 수행된다면 lock이 필요하지 않습니다.
하지만 write에서 lock이 걸린 상태면, read할때도 lock을 요청해봐야 지금 write가 lock을 건 상태인지 아닌지 알수 있겠죠?
기술적으로 말해서 lock 이라는건 그 대상을 잠그는게 아니라... lock 자기 자신만을 잠그는 겁니다.
그래서 말씀하신대로 read lock과 write lock을 구분하기도 하는데요,
이 경우 read lock만 여러개 걸리는것은 허용하지만, write lock을 걸려면 read lock이 하나도 걸려있지 않아야 하고
write lock이 걸려있는 동안은 read lock을 걸수 없습니다.
명확한 답변 감사합니다. 정리안되던게 명쾌해졌습니다.
명확한 답변 감사합니다. 정리안되던게 명쾌해졌습니다.
댓글 달기