2012-01-21 2 views
1

공유 뮤텍스를 사용하여 벡터/맵/무엇이든 읽는 대신 쓰여지는 경우에만 스레드가 잠기도록하고 싶습니다. 하지만 func1() 결코 잠금을 해제 할 수 있기 때문에 func2()는 uniqueue 잠금을 결코 얻지 못할 것 같아요. 고유 잠금을 얻으려고 할 때 shared_mutex에서 같은 스레드 잠금을 계산하지 않는 방법이 있습니까? 아니면 여전히 문제가 발생합니까?데드락 공유 부스트 뮤텍스 방지

나는 모든 스레드가 func2()에 도달하거나 잠금을 해제하면 강제로 잠금 (한 번에 한 스레드)을 얻을 수있는 방법을 찾아야한다고 생각합니다.

func2() 
{ 
    boost::unique_lock<boost::shared_mutex> lock_access3(shared_mutex); 
    /*stuff*/ 
    lock_access3.unlock(); 
} 

func1() 
{ 
    boost::shared_lock<boost::shared_mutex> lock_access1(shared_mutex); 
    func2(); 
    lock_access1.unlock(); 
} 

답변

0

두 가지 당신이 할 필요가있다.

2) 잠금이 이미 보유 된 상태에서 func2이 호출되었으므로 잠금을 획득하려고 시도하면 안됩니다.

+0

func1 읽습니다. 읽기 후에는 func2()를 호출 할 수도 있고 호출하지 않을 수도 있습니다. mutexes (그리고 일반적으로 C++)에 대한 새로운 것이 어쩌면 그 해결책은 정말 쉽습니다. 나는 그것을 보지 못했습니다. – natli

+0

그래서'func1'은 쓰기 연산을 구현합니다 ("어쩌면 쓰기"연산은 쓰기 연산의 한 유형입니다).'func2'를 호출하여 수행하는 것은 무의미합니다. 쓰기 조작을 수행하는 함수는 배타적 잠금을 확보해야합니다. –

+0

func1이 매우 길면 어떻게됩니까? 처음에 손상되지 않도록 보호하려는 벡터/맵/힙을 변경하지 않으면 다른 스레드가 완료 될 때까지 기다릴 필요가 없습니다. – natli

2

재귀 뮤텍스를 사용해야한다고 생각합니다. 이 질문에 좋은 설명을 참조하십시오 :

부스트는 boost:recursive_mutex 수업이 제공합니다. 그것은 배타적 잠금이 아닌 공유 잠금을 획득 할 필요가 func1 이후

1) 쓰기 작업을 구현

+0

리더/라이터 (공유/독점) 잠금이 필요하기 때문에 도움이되지 않습니다. –