Najprostszy sposób sygnalizowania zdarzenia kilku procesom w .NET

Question

Miałem nadzieję, że istnieje prosty sposób sygnalizowania zdarzenia kilku procesom, które nie wymagały napisania niestandardowego detektora gniazda. Próbuję poinformować kilka aplikacji, które będą musiały zaktualizować buforowane ustawienia konfiguracyjne, które spowodowały zmianę konfiguracji. Chciałem zaimplementować singleton "host-wide", ale nie znalazłem żadnych przykładów. Czy to możliwe?

Answer 1

Można użyć uchwytów oczekiwania cross-procesowe. Sprawdź ten znakomity numer threading tutorial, aby uzyskać więcej informacji.

Możesz użyć uchwytów oczekiwania w klasie singleton, aby utworzyć coś w rodzaju singletonu. Oto wszystko, co musisz wiedzieć o singleton pattern in C#.

Jedna możliwa implementacja: singleton może reprezentować ustawienia konfiguracyjne. Przed pobraniem ustawienia można sprawdzić sygnaturę czasową pliku, który przechowuje buforowane ustawienia konfiguracji. Dostęp do odczytu/zapisu pliku można chronić za pomocą uchwytów oczekiwania.

Jeśli nie chcesz używać uchwytów oczekiwania, możesz ustawić sygnaturę czasową w rejestrze. Pobieranie i ustawianie wartości rejestru są operacjami atomowymi, więc są one automatycznie wątkowane. Pamiętaj jednak, że wymaga to uprawnień rejestru, więc może to być niepożądane, chyba że masz pewność, że użytkownicy mają wymagane uprawnienia.

Answer 2

Nazwany semafor i Nazwane mutex są używane do synchronizacji międzyprocesowej.

Msdn mówi:

Semafory są dwojakiego rodzaju: lokalne semafory i nazwane semafory systemowe. Jeśli utworzysz obiekt Semaphore za pomocą konstruktora, który akceptuje nazwę, jest on powiązany z semaforem systemu operacyjnego o tej nazwie. Nazwane semafory systemowe są widoczne w całym systemie operacyjnym i mogą być używane do synchronizowania działań procesów.

Msdn mówi:

nazwane muteksy systemowe są widoczne w systemie operacyjnym i może być używany do synchronizacji działania procesów. Możesz utworzyć obiekt Mutex, który reprezentuje nazwany system mutex, używając konstruktora, który akceptuje nazwę. Obiekt systemu operacyjnego może być utworzony w tym samym czasie lub może istnieć przed utworzeniem obiektu Mutex.

Nadzieja to pomaga

Answer 3

Możesz użyć nazwanego EventWaitHandle. Będziesz jednak potrzebował również sposobu na zresetowanie zdarzenia po powiadomieniu wszystkich procesów nasłuchiwania. Prawdopodobnie możesz zrobić coś takiego, jak ustawić zdarzenie, a następnie zresetować je po krótkim czasie: jednej sekundy lub pięciu sekund. Klienci mogą wiedzieć, że zdarzenie nie uruchomi tego szybko po kolei.

Inną możliwością jest użycie nazwanego semafora. Ale wtedy musisz wiedzieć, ilu słuchaczy jest, abyś mógł ustawić początkowe i maksymalne wartości Semafora.

Są sposoby na robienie tego, o co prosisz, bez konieczności budowania czegoś wyjątkowego.

Answer 4

Dla szczelnie połączonego modelu wydawca/abonenta (gdzie wydawcą jest wyraźnie świadomy wszystkich abonentów):

• Można użyć semafora ustawiony przez wydawcę i mają wszyscy abonenci czekać na niego. Jeśli jednak któryś z subskrybentów zginie, twoja liczba zostanie odrzucona. Będziesz musiał zaimplementować jakąś formę wykrywania zombie:

• Możesz użyć punktów połączenia COM. Wymaga to rejestracji administratora klas COM i bibliotek typów.

luźno powiązanych modelu wydawca/abonenta (jeśli wydawca nie zna anythig o abonentów):

• Jeśli konfiguracją settigns są przechowywane w pliku lub w rejestracji, subskrybenci mogą zaimplementować plik lub rejestrujący zmianę rejestru. Niestety to rozwiązanie jest ograniczone do zmian w pliku/rejestrze, nie skaluje się i może podlegać opóźnieniom w zależności od obciążenia systemu plików/rejestru.

• Można użyć COM + luźno Imprezy (poprzez System.EnterpriseServices). Jednak może to być przesada dla Ciebie ze względu na złożoność LCE.

• Możesz wysyłać wiadomość okna, które wydawca zarejestrował przez RegisterWindowMessage do wszystkich ukrytych okien najwyższego poziomu dla danej klasy. Wszyscy subskrybenci będą musieli utworzyć jedno takie okno. Wymagałoby to pewnych zależności między Win32, ale jest prawdopodobnie najlżejszym sposobem na wdrożenie luźno powiązanego wydawcy/subskrybenta.