std::lock_guard 에 대한 의문점들...? about cppconcurrencyinaction HOT 8 CLOSED

저도 3장 앞부분은 제대로 다 읽어보지 않아서 확실하지 않지만
우선 1. 번 이유는 책에 명시적으로 적혀있습니다.

우선 std::unique_lock 이 존재함에도 ( lock_guard 와 같은 동작이 가능 함에도 )
std::lock_guard 를 쓰는건 unique_lock 에는 소유권에 대한 flag 가 추가적으로 존재하기 때문에
더 많은 저장 공간을 필요로 하고 같은 이유로 조금 더 느리기 때문에,
가능하다면 std::lock_guard 를 쓰기를 권장합니다. ( 저자가 말하길 )

std::lock_guard 는 unlock 가능하지만 아마도 java 에서 함수명에 synchronize 를 붙이는것 처럼 쓰기를 의도하고 만든게 아닌가 싶습니다.

from cppconcurrencyinaction.

lock_guard의 동작:
RAII로 개발자의 실수를 방지하는, 일종의 신뢰성 보장이라고 생각됩니다.
소멸자에서 예외처리가 발생하지 않도록 내부적으로private 검사가 있을것이라 생각되네요.

사용처:
함수라기보다는, 코드블럭 단위로 조정하기위해 존재하는것 같습니다. 블록 로컬변수가 범위scope를 벗어나면 소멸하는 점을 이용한게
아닐까요?
2015. 12. 3. 오후 4:45에 "DoO" [email protected]님이 작성:

std::lock_guard 사용 이후 std::mutex unlock

std::lock_guard() 를 사용하였을때 아래와 같이 사용하는것이 올바른 코드 작성 법 일까요?

std::mutex some_mutex;
void lockGuardTest()
{
std::lock_guardstd::mutex guard(some_mutex);

some_mutex.unlock();

}

std::lock_guard() 를 사용한 이후에 std::mutex 를 unlock 이후 std::lock_guard 동작이
궁금해서 테스트 해 보았는데 이상없이 동작 하였습니다.
std::lock_guard 의 사용 이유? 사용처?

아래와 같은 이유 때문에 std::lock_guard 를 사용하는 걸까요?

1. 소멸자에서 mutex 에 대한 unlock 이 이루어 지므로 개발자의 실수로 unlock 을 방지
2. 선언이후에 부분에 대하여 모든 부분을 보호
3. unlock 코드를 넣지 않어 코드의 간결성 유지

그리고 std::lock_guard 와 std::unique_lock 이 있습니다.
std::lock_guard 는 멤버 함수가 없습니다. 그러면 std::lock_guard 는 선언 이후에 별다른 처리를 못하고
소멸자가 unlock 을 자동으로 해주는 기능만 있는거 같습니다.
그에 반해 std::unique_lock 은 멤버 함수가 존재 합니다. 여러 operation(lock, unlock) 을 수행 할수
있습니다.
그러면 std::lock _guard는 함수 단위로 lock 를 걸때 사용해야 할까요?
(java 에서 함수명에 synchronize 를 붙이는것 처럼)
참고 자료

http://en.cppreference.com/w/cpp/thread/lock_guard
http://en.cppreference.com/w/cpp/thread/unique_lock

—
Reply to this email directly or view it on GitHub
#4.

from cppconcurrencyinaction.

신뢰성 보장 이라면 중간에 lock_guard 로 보호하는 mutex 를 직접 unlock 을 수행해도 괜찮다는 의미로 받아 드려도 될까요?

제 생각에는 'lock_guard 를 사용 하였으면 그 scope 에서는 mutex 에 직접 접근은 하지 말자' 로 이해 할수도 있는것 같습니다.

뭐 어짜피 강제 되어 있는 사항들은 아니지만 어느 방법으로 사용하는게 좋을까나 하는 의문이어서...

from cppconcurrencyinaction.

스택 오버 플로우에 unique_lock 과 lock_guard 에 대한 이야기 있어서 추가 합니다.

스택오버플로우 링크

from cppconcurrencyinaction.

아, 제가 말하는 신뢰성은 리소스 클린업 이슈입니다. 잠금을 해제하지 않고 루틴이 종료되는것은 피해야하니 그 부분에 대해 신뢰성이
보장된다는 의미였습니다.
2015. 12. 4. 오후 12:54에 "DoO" [email protected]님이 작성:

신뢰성 보장 이라면 중간에 lock_guard 로 보호하는 mutex 를 직접 unlock 을 수행해도 괜찮다는 의미로 받아 드려도
될까요?

제 생각에는 'lock_guard 를 사용 하였으면 그 scope 에서는 mutex 에 직접 접근은 하지 말자' 로 이해 할수도
있는것 같습니다.

뭐 어짜피 강제 되어 있는 사항들은 아니지만 어느 방법으로 사용하는게 좋을까나 하는 의문이어서...

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

from cppconcurrencyinaction.

네 신뢰성 부분은 저도 비슷 하게 이해 했습니다.
mutex 를 unlock 을 하지 않고 lock scope 를 벗어 나게 된다면 deadlock 이 발생 하겠지요..

하나 궁금한것은 std::lock_guard 를 사용하였을때 mutex를 이용하여 unlock 을 쓸 필요가 있냐는것 입니다.

from cppconcurrencyinaction.

reference 에 명시 되어 있네요..
Notes
std::mutex is usually not accessed directly: std::unique_lock and std::lock_guard are used to manage locking in exception-safe manner.

http://en.cppreference.com/w/cpp/thread/mutex

std::mutex 는 직접적으로 호출 하지 않는편이 좋겟네요..

from cppconcurrencyinaction.

NAVER - http://www.naver.com/

[email protected] 님께 보내신 메일 <Re: [CppConcurrencyInAction] std::lock_guard 에 대한 의문점들...? (#4)> 이 다음과 같은 이유로 전송 실패했습니다.

받는 사람이 회원님의 메일을 수신차단 하였습니다.

from cppconcurrencyinaction.