.NET PropertyGrid 스레드 안전성

Question

나는있다 PropertyGrid 내 응용 프로그램에서 임의의 객체를 편집하는 데 사용됩니다. 다른 스레드에서 임의의 서브 루틴을 실행할 수 있어야합니다.이 객체 (검색 기능, 궁금한 경우). 명백한 문제는 사용자가 내 검색 스레드를 읽는 동시에 이러한 객체 중 하나를 편집 할 수 있다는 것입니다. 피하는 것이 바람직합니다 (검색 스레드가 읽는 것이기 때문에 중요한 것은 없을 것입니다. 글을 쓰지 않음).

부름 lock(obj) 내 검색 스레드에서 충분히 쉽지만 Reflector의 PropertyDescriptorGridentry 코드를 통해 문서와 짧은 탈지를 한 후 System.Threading.Monitor.Enter()/Exit() PropertyGrid의 해당 물체를 호출하십시오. 나는 이것을 충분히 단순하게 만들 수있는 간단한 사건과 엔디드 사건이 있기를 바랐지만 그런 것을 찾을 수없는 것 같습니다. 다른 객체가 선택 될 때까지 내 검색 스레드를 차단하기 때문에 PropertyGrid에 표시되는 동안 전체 객체를 잠그지 않을 것입니다.

나는 Windows 양식의 스레딩 모델에 약간 새로운 것이므로 방금 간과 한 명백한 대답이 있기를 바랍니다. 도움이 있습니까?

편집하다: 검색을 비동기로 실행하기 전에 객체를 동기로 복제하는 것은 검색 자체를 동기식으로 실행할 수있을 정도로 비효율적 일 수 있습니다. 물론 검색을 실행하는 동안 사용자가 계속 작동 할 수 있도록하는 것입니다. 내가 겪고있는 데이터 세트가 결국 임의로 커질 수 있으므로 검색은 잘 확장되어야합니다. 이는 동기 복제가 내가 피하려는 유용성 문제를 일으킬 것 같은 것처럼 보이게합니다.

Answer 1

나는 당신이 이것을 위해 꽤 많은 일을해야한다고 생각합니다.

먼저, ICUSTOMTYPEDESCRIPTOR의 구현을 만들어야하며,이 유형에 대해 일반적으로 얻을 수있는 타이핑자를 기반으로 구현을 기반으로합니다.

그런 다음, 잠그고 자하는 구성원의 설명자를 노출시키는 메소드의 구현에서 해당 설명자에서 파생 된 서브 클래스를 제공하고 적절한 방법을 재정의하여 잠금 장치를 포장합니다.

따라서 속성의 경우 GetProperties를 구현하여 PropertyDescriptor의 특정 서브 클래스를 반환합니다. 이 서브 클래스는 getValue 및 setValue 메소드 (및 기타)를 무시하고 해당 변수에 액세스 할 때 잠금을 사용합니다.

UI 스레드에서 이와 같이 잠그는 것은 아마도 해당 스레드의 작업을 임의로 차단하고 싶지 않기 때문에 아마도 나쁜 생각 일 것입니다. 객체의 클론을 만들고 완료되면 물체 저장을 업데이트하는 방법을 갖는 것이 더 나을 수 있습니다.

Answer 2

그것은 실제로 실 안전하지 않을 것입니다. UI 스레드에 대한 검색 코드의 비트를 마샬링 할 수는 있지만 속도가 느려질 것입니다.

검색은 얼마나 빨리 있어야합니까? 클론에 대항하여 일할 수 있습니까? 등

Answer 3

데이터를 표시하기 전에 데이터를 복제하고 검색 스레드가 클론에서 작동하도록 할 수 있습니까? 검색 스레드가 "보기"변경을 원한다면 이벤트에 응답 할 수 있습니다. PropertyGrid 그리고 아마도 만들 수 있습니다 제어 어떻게 든 클론이 변경됩니다. (그래도 "오래된"데이터 만 사용하는 것이 더 쉽습니다.)

나는 복제 데이터가 비효율적으로 비효율적으로 들리지만, 각 스레드가 완전히 독립적 인 데이터에서 작동 할 때 (또는 모든 스레드 만 읽는) 스레드는 확실히 더 간단합니다.

Answer 4

나는 틀릴 수 있지만 당신이 잘못된 끝에서 오는 것 같습니다.

해결해야 할 두 가지 문제가 있습니다.

첫째, PropertyGrid가 UI 스레드에서만 액세스하는지 확인하십시오. 다른 스레드에서 그 방법 (속성 게터/세터 포함)이 액세스되면 신비한 방식으로 고통을 겪을 것입니다. 예외는입니다 InvokeRequired() 그리고 Invoke, 물론이야.

둘째, 검색 스레드가 제대로 실행될 수 있는지 확인하십시오.

첫 번째 문제를 해결하기 위해 어느 하나 객체가 수정되지 않은지 확인하십시오 제외하고 UI 스레드에 의해 또는 모든 이벤트 트리거 스레드를 인식하여 객체 이벤트 (예 : PropertyChanged)가 UI 스레드에서만 트리거되도록합니다.

두 번째 문제는 더 쉽습니다. 검색 스레드가 핵심 개체에서만 읽는 한 모든 것이 잘 작동해야합니다. 예, 검색 스레드가 부주의하게 부분적으로 업데이트 된 데이터를 볼 수 있지만 실제로 문제가 있습니까?

몇 가지 마지막 생각 ...

• PropertyGrid 자체를 반복하기 위해 검색을 구현하지 마십시오. 객체 목록을 앞쪽으로 얻으십시오 (클론 일 필요는 없습니다) 대신 작업을 수행하십시오.

• 유휴 처리를 사용하여 검색을 수행하는 것을 고려해 보셨습니까? 그만큼 Application 객체는 응용 프로그램이 처리를 위해 메시지가 부족할 때마다 이벤트를 시작합니다.이 행사가 시작될 때마다 검색의 1 단계를 수행 할 수 있습니다. 불쌍한 맨 스레딩의 종류이지만 뮤 테스/잠금/세마 폰 두통이 없습니다. 나는 이것을 과거에 아주 좋은 효과로 사용했습니다.

업데이트: 내가 올바르게 기억한다면, PropertyGrid는 IEditableObject 인터페이스, 호출 BeginEdit 행 수정을 시작하자마자 EndEdit 다른 행으로 이동할 때. 검색 스레드가 불완전한 변경 사항을 보지 못하도록이를 활용할 수 있습니다.

업데이트 2: 다음, 나는 당신이 이미 알고있는 것을 발견했습니다 - 그 PropertyGrid 그렇지 않습니다 IEDIBLEOBJECT 인터페이스를 존중하십시오.

나는 또 다른 제안이 있습니다 - 당신이 투자하고 싶은 것보다 더 많은 일일 수도 있습니다.

System.Transactions 네임 스페이스가 .NET 2.0에 도입 된시기에 주변 트랜잭션을 사용하여 객체에 대한 스레드 분리를 제공하는 것에 관한 기사를 보았습니다. 아이디어는 객체 속성에 듀얼 스토리지가 있다는 것입니다. 먼저 모든 스레드에 보이는 커밋 된 값을 가지고 있으며, 헌신적 인 값을 스레드별로 저장하는 데 사용되는 스레드-로컬 변수가 있습니다. 속성이 수정되면 객체는 스레드 로컬에 새 값을 저장하여 주변 거래에 입대합니다. 트랜잭션이 저격하거나 롤백되면 스레드 값이 저장되거나 폐기됩니다.

불행히도 CSLA 가이 지원을 제공하는 것 같습니다. 도움이 되었기를 바랍니다.