.NET 이벤트 발사 및 처리에 대한 모범 사례

Question

잠금 (예 : 중요 섹션) 내부에서 발생하는 이벤트는 교착 상태에 빠지기 쉽습니다. 이는 이벤트 처리기가 일부 비동기 작업에서 차단해야 할 수도 있기 때문입니다 같은 자물쇠를 사십시오.

가 잠금 내부 이벤트를 발생하기 위해 필요한 경우

1. 후 항상 비동기 이벤트를 발생 : 자, 디자인 현명한 내 마음에 와서 두 가지 가능한 솔루션이 있습니다. 예를 들어, 이벤트 발사 순서가 중요하지 않은 경우 ThreadPool을 사용하여이 작업을 수행 할 수 있습니다. 이벤트의 순서를 보존해야하는 경우 단일 이벤트 실행 스레드를 사용하여 순서대로 이벤트를 시작하지만 비동기 적으로 시작할 수 있습니다.

2. 이벤트를 발생시키는 클래스/라이브러리는 교착 상태를 방지하고 잠금 내에서 이벤트를 시작하기 위해 필요한 예방 조치를 취할 필요가 없습니다. 이 경우 이벤트 핸들러 내부에서 잠금 (또는 다른 차단 조작)을 수행하는 경우 비동기 적으로 이벤트를 처리하는 것은 이벤트 핸들러의 책임입니다. 이벤트 처리기가이 규칙을 따르지 않으면 교착 상태가 발생할 경우에 대비해야합니다.

솔직히 두 번째 옵션은 이벤트 처리기 또는하지 않을 수 있습니다 무엇을 추측해야하는 이벤트 발사 코드와 같은 원리의 분리 측면에서 더 낫다고 생각합니다.

그러나 실제적으로 두 번째 옵션은 모든 이벤트 처리기가 모든 이벤트 처리 코드를 비동기식으로 실행해야하는 시점으로 수렴되는 것 같으므로 첫 번째 경로를 택할 것입니다. 대부분의 경우에는 일부 일련의 호출이 차단 작업을 수행하는지 여부를 결정합니다. 복잡한 이벤트 처리기의 경우 가능한 모든 경로를 추적하고 코드가 전개됨에 따라 경로를 추적하는 것은 쉬운 일이 아닙니다. 따라서 문제를 한 곳에서 해결하는 것이 바람직합니다.

간과 할 수있는 다른 대체 솔루션이 있는지, 그리고 가능한 장점/단점과 함정이 각각의 가능한 해결책에 기인하는지 보는 데 관심이 있습니다.

이런 상황에서 가장 좋은 방법이 있습니까?

Answer 1

세 번째 옵션이 있습니다. 잠금을 해제 할 때까지 이벤트를 발생시키는 지연입니다. 일반적으로 잠금은 잠시 동안 수행됩니다. 일반적으로 잠금 후까지 이벤트 발생을 지연시킬 수 있습니다 (단, 동일한 스레드에서).

BCL은 잠금 상태에서 사용자 코드를 호출하지 않습니다. 이것은 그들의 명시적인 설계 원칙입니다. 예를 들어 ConcurrentDictionary.AddOrUpdate은 이 아니며은 자물쇠로 잠겨있는 동안 공장에 전화합니다. 이 반 직관적 인 동작은 같은 키에 대해 여러 팩터 리 호출을 유발할 수 있으므로 많은 스택 오버플로 질문을 발생시킵니다.

Answer 2

솔직히 이벤트 발사 코드는 이벤트 처리기가 수행할지 여부를 추측해서는 안되기 때문에 두 번째 옵션은 관심 원칙의 분리 측면에서 더 좋습니다.

첫 번째 옵션이 우려 사항을 위반하지 않는다고 생각합니다. (분명 완료되지 않음) 같은 것을 AsyncEventNotifier 클래스를 추출하고 여기에 이벤트 발생 객체의 대리자를 가지고 :

class AsyncEventNotifier 
{ 
    private List<EventListener> _listeners; 

    public void AddEventListener(EventListener listener) { _listeners.add(listener); } 
    public void NotifyListeners(EventArgs args) 
    { 
     // spawn a new thread to call the listener methods 
    } 
    .... 
} 

class EventGeneratingClass 
{ 
    private AsyncEventHandler _asyncEventHandler; 

    public void AddEventListener(EventListener listener) { _asyncEventHandler.AddEventListener(listener); } 

    private void FireSomeEvent() 
    { 
     var eventArgs = new EventArgs(); 
     ... 
     _asyncEventhandler.NotifyListeners(eventArgs); 
    } 
} 

은 이제 원래의 클래스가 이전에 대해 책임을지지 않습니다이었다 아무것도에 대한 책임을지지 않습니다.리스너를 자신에게 추가하는 방법을 알고 있으며 리스너에게 이벤트가 발생했음을 알리는 방법을 알고 있습니다. 새로운 클래스는 "청취자에게 이벤트가 발생했음을 알립니다"라는 구현 세부 사항을 알고 있습니다. 리스너 순서는 중요한 경우 보존됩니다. 아마도 그렇게해서는 안됩니다. listenerA가 이미 처리 할 때까지 listenerB가 이벤트를 처리 할 수없는 경우 listenerB는 수신 대기중인 객체보다 listenerA가 생성 한 이벤트에 더 많은 관심을가집니다. 이벤트가 처리되어야하는 순서를 알아야하는 또 다른 클래스가 있어야합니다.