동일한 변수 - UI 스레드와 타이머 스레드를 참조하는 두 개의 스레드가 있습니다. 따라서 두 스레드의 lock 문에서이 스레드에 대한 액세스를 래핑했습니다. 타이머 스레드의 액세스 우선 순위 - 변수를 사용하고 UI 스레드가 또한 액세스하려는 경우 UI 스레드의 작업을 완료 할 수 있지만 타이머 스레드의 작업이 완료된 후에.멀티 스레드 동기화를위한 올바른 패턴? (C#)
그러나 타이머 스레드 은 UI 스레드로 다시 위임 할 수 있으므로 UI 스레드는이를 처리 할 수 있어야합니다. 이를 수용하기 위해 UI 스레드가 세 번째 스레드를 실행하여 해당 작업 (세 번째 스레드)이 타이머 작업이 완료 될 때까지 기다릴 수 있고 UI 스레드를 사용할 수 있도록합니다. 잠금은 세 번째 스레드에서 발생합니다.
이러한 종류의 동기화에 사용해야하는 올바른 패턴은 무엇입니까?
중요한 섹션에서 일어나는 모든 일이 가능한 한 간단해야한다는 것이 일반적인 권장 사항입니다. 특히 중첩 된 잠금은 피해야합니다. 중첩 된 잠금은 잠재적으로 교착 상태의 원인입니다.
'타이머'스레드에서 수행하는 작업에 적용 할 때 중요한 섹션을 처리와 분리해야합니다. 타이머 스레드의 IOW는 일반 변수에서 데이터를 검색 한 다음 잠금 외부의 UI 스레드와의 상호 작용을 포함하여 나머지 처리를 수행합니다.
믹스에 세 번째 스레드를 추가하는 것은 당신의 삶에 따라 어떤 쉽게
"KISS"알림을 보내 주셔서 감사합니다. – redman
일반적인 규칙하지 않습니다 당신이 잠금을 시간을 최소화하고, 당신이 돈 코드를 호출하지 않는다는 것입니다 잠금을 유지하면서 소유 및 제어 (예 : 이벤트, 가상 메서드 또는 UI 스레드)
그래서 잠금을 유지하는 동안 타이머가 UI를 다시 호출해서는 안됩니다. 잠금 (읽기, 호출 UI, 쓰기) 아래의 데이터에 대한 트랜잭션 액세스가 필요한 경우에는 롤백 및 재 시도가 가능하도록 설계해야합니다.
어림짐작 가능한 짧은 시간 동안 밝은 잠금을 사용하는 것이다.
꽤 좋은 여기에 기사가있다 : mfeingold 말했듯이 가능 http://www.moserware.com/2008/09/how-do-locks-lock.html
이 그것을 피하기가. 피할 수없는 곳에서 두 스레드의 잠금을 같은 순서로 수행하도록주의하십시오! A-> B-> C
다음 교착이 가능 ...
중첩 잠금 장치는 일반적으로 성능을 비용 다른 스레드로부터.
왜이 작업을 수행하고 있습니까? 복잡하고 오류가 발생하기 쉽습니다.
UI 스레드에 위임 한 타이머 스레드 란 무엇입니까?
필요할 수도 있지만 즉각적인 조치는 설계를 불필요하게 복잡한 동기화 문제로 밀어 넣을 지 고려해야합니다.
당신이 옳을지도 모릅니다. 나는 결코 재평가를 반대하지 않습니다. 타이머 스레드는 다음 두 가지 시나리오에서 UI 스레드로 위임합니다. 1. UI 스레드에서 인스턴스화 된 UI로 출력하는 개체를 호출합니다. 이 객체의 모든 인스턴스가 이러한 UI를 사용하는 것은 아닙니다. (이것에 대해서는 좋은 패턴을 가지고 기꺼이 드리겠습니다.) 2. 만든 스레드에서 호출해야하는 타사 개체가 호출됩니다 (이 경우 UI 스레드). – redman
UI 작업을 동 기적으로 수행해야합니까 (완료 할 때까지 기다려야합니까?) 그렇지 않은 경우 UI 스레드에 대한 호출을 비동기 적으로 수행하는 것을 고려할 수 있습니다. 그러면 교착 상태가 발생할 가능성을 피할 수 있습니다. – Phil
덜 일반적인 답변에 대해서는 세부 정보가 필요합니다. 두 쓰레드가 공유 변수를 읽거나 쓰고 있습니까? UI 스레드에 "위임"하는 동안 실제로 타이머 스레드가 차단해야합니까? 일반적으로 교착 상태를 피하기 위해 제 3 스레드를 사용하지 않기 때문에 복잡성을 줄이려고합니다. – peterchen