잠금 장치가 추상화 및 합성 가능성 원칙을 위반했다고하는 이유는 무엇입니까?

Question

나는이 질문에 대답하기 위해 Google이나 StackOverflow에 대한 답을 찾지 못했습니다. 나의 이해에서

추상화

잠금을 깰 수 잠금을 사용

• 스레드는

작성 가능하지 않습니다하지만 어떻게 그리고 왜 않는 잠금 휴식 추상화와 조합 성?

Answer 1

저는 전문가가 아니기 때문에 온라인으로도 찾을 수 없었습니다. 나는 아마도 유니 (uni)에서 당신과 같은 주제를하고 있습니다. 그리고 여기에 제가 생각해 낸 것이 있습니다 (개인적인 경험으로 말하기).

이슈는 추상화의 원칙에 따라 잠금을 설정하면 잠금 상태와 리소스가 현재 실행중인 명령어 세트의 상태에 의해 결정되지 않을 수 있습니다. 예를 들어, C++에서는 Baker 클래스를 사용할 수 있습니다.이 클래스는 오븐 객체에 대한 상호 배타적 액세스가 필요합니다. 빵 굽는 사람은 오븐을 아주 자주 (열기/닫기/안에 물건 넣기) 사용해야하고 오븐에 독점적으로 접근해야합니다. 그러나이 기능은 상호 배타적 인 접근이 그의 기능에 중요 할 수 있다고 정확하게 요구할 때만 가능합니다 .

시스템에 Baker와는 별도의 기능을 추가해야하지만 베이커가 사용하는 동일한 오븐에 상호 배타적 인 액세스가 필요합니다. 이러한 변경 사항을 구현할 때 잠금이 여러 스레드의 상태에 동시에 의존하기 때문에 이전에 추상화 된 Baker 클래스의 동작이 프로그램의 런타임에서 동일하게 유지된다는 보장은 없습니다. (예 : 오븐이 다른 실에 의해 사용되는 경우 빵 굽는 사람은 오븐이 다시 자유 로워 지는지 확인하기 전에 30 분을 기다려야 결정할 수 있습니다. 이는 원치 않는 비효율적 인 행동 일 수 있습니다).

동일한 문제로 인해 프로그램의 서로 다른 구성 요소가 모두 멀티 스레드 응용 프로그램에서 잠재적으로 정의되지 않은 동작에 의존하는 경우 잠금이 원활하게 구성 될 수 없으므로 잠금은 구성 가능성 원칙에도 위배됩니다.

도움이 되길 바랍니다. 우리가 함께 할 수 있도록 내 생각을 알려주세요.