Zugriff zweier Prozesse auf eine Singleton Klasse

[Gateway_man]

Hallo,

ich verstehe das gerade nicht.

Ich habe eine Singleton Klasse die als Schnittstelle zwischen zwei Prozessen fungieren soll.

Der eine Initialisiert diese mit gewissen interfaces und der andere Process holt sich die Instanzen.

Beim Test greift der Prozess der sich die Instanz holen soll jedoch ständig ins leere.

Der bekommt immer Null zurück.

So nun meine Frage:

Kann es sein das Singleton Klassen nur innerhalb eines Prozesses funktionieren?

Wir machen das sehr oft in der Arbeit, jedoch greift immer der selbe Prozess auf die Instanzen zu.

An sich wäre es logisch das es nicht funktioniert, da effektiv Prozess A auf den Speicherbereich von Prozess B zugreifen würde.

Effektiv geht es um folgendes.

Ich habe einen Service und suche jetzt nach Möglichkeiten wie ich es schaffe das das Administrationstool (gui Anwendung) mit dem Service kommunizieren kann.

Da schien mir Singleton als sehr geeignet....

Natürlich bin ich auch für alternative Vorschläge zu haben.

LG

Gateway

[Guybrush Threepwood]

Kann es sein das Singleton Klassen nur innerhalb eines Prozesses funktionieren?

Natürlich, eine Singleton ist letzten Endes auch nix anderes wie eine normale Instanz einer Klasse und wie du ja schon gemerkt hast hat jeder Prozess seinen eigenen Speicherbereich und somit seine eigenen Variablen.

Ich habe einen Service und suche jetzt nach Möglichkeiten wie ich es schaffe das das Administrationstool (gui Anwendung) mit dem Service kommunizieren kann.

Da gibts viele Möglichkeiten. welche die Beste ist hängt davon ab was genau kommuniziert werden soll.

[Gateway_man]

Hi,

danke für die Bestätigung , hab zwischenzeitlich schon einiges darüber erfahren.

Im .NET gibt es wohl nur die Möglichkeit per Remoting (WCF) zwei Prozesse zu Synchronisieren.

Das gefällt mir persönlich nicht so gut aber wenn es nicht anders geht .

Im Prinzip will ich diverse Schnittstellen übergeben die vom Service initialisiert wurden.

Diese Schnittstellen verfügen über events, Properties und Funktionen.

Allerdings muss ich das bei der Nutzung von Remoting nochmal umdesignen.

So ganz nebenbei hätte ich dazu aber dann doch noch eine Fragen.

Wie verhält es sich dann bei folgendem Beispiel:

Man hat eine Funktion die man über pInvoke aufruft.

Diese Funktion verfügt über einen IntPtr Parameter und dieser zeigt auf eine Structure.

Das funktioniert auch.

Hat die externe Funktion dann nicht Zugriff auf den Speicherbereich meiner .NET Anwendung?

lg

Gateway

[Klotzkopp]

Im .NET gibt es wohl nur die Möglichkeit per Remoting (WCF) zwei Prozesse zu Synchronisieren.

Erstens sind Remoting und WCF zwei unterschiedliche Dinge, und zweitens gibt es noch diverse andere IPC-Möglichkeiten, wie Memory Mapped Files, Sockets oder Named Pipes.

[Gateway_man]

Erstens sind Remoting und WCF zwei unterschiedliche Dinge, und zweitens gibt es noch diverse andere IPC-Möglichkeiten, wie Memory Mapped Files, Sockets oder Named Pipes.

So wie mir das erklärt wurde, werden bei Remoting TcpChannels registriert und deren Kommunikation wird mit Windows Comunication Foundation umgesetzt.

Aber gut ich lass mich gerne eines besseren belehren.

Vielen Dank für die zusätzlichen Schlüsselbegriffe, ich denke ich werd mich mal über die Named Pipes etwas besser informieren.

LG

Gateway

[Gateway_man]

Hm,

das ist ja alles total umständlich und ich müsste enorm viel schreiben um das einigermaßen so umzubiegen das es für mich brauchar wäre.

Bei dem aktuellen Projekt spielen Events eine entscheidende Rolle.

Aber bei keinem der Lösungsvorschläge wäre das möglich, da immer nur der Wert übergeben wird.

Wenn also der Prozess A ein Event eines Objektes wirft, merkt Prozess B das nicht, weil beide Objekte jeweils getrennt initialisiert wurden (nur eben mit gleichem Inhalt).

Ich dachte schon fast dass das die Lösung ist.

Bis ich merkte das auch hier der Prozess B nicht auf die selbe Instanz des Objektes zugreift.

Warum nennt man das dann bitte Shared Memory. So ein Unsinn.

Unter Shared Memory verstehe ich einen Speicherbereich auf dem beide Prozesse Zugriff haben. Und wenn ich dann ein Objekt in diesem Speicherbereich ablege dann sollen beide Prozesse auch auf die selbe Speicheradresse zugreifen wenn diese auf das Objekt zugreifen.

Gibts da eine Möglichkeit? Muss auch nicht .Net sein . Kann auch gerne in den unendlichen tiefen von Windows versteckt sein.

Ich sehe es ja ein das es einen Schutz gegen fremden Speicherzugriff geben sollte. Aber wenn ich als Entwickler explizieht möchte das Prozess XY Zugriff auf meinen Speicherbereich hat dann sollte mir auch so eine Möglichkeit geboten werden.

Da kann ich genauso gut das Objekt serialisiert auf die Platte ablegen und der Prozess B lässt im Timer auf existenz der Datei prüfen und deserialisiert diese dann. Wow was für ein Shared Memory .

Lg

Simon

Bearbeitet 2. August 2012 von Gateway_man

[realgun]

Also wenn Du bei google nach "IPC C#" suchst, findest Du eine ganze Menge brauchbare Sachen zur Kommunikation zwischen unterschiedlichen Prozessen.

SharedMemory ist ein gemeinsamer Speicherbereich, aber eher so zu verstehen wie die "Zwischenablage". Events von den Objekten da drin wirst Du wohl nicht mitbekommen.

Das Prinzip von IPC unter Windows ist eher der Austausch von Nachrichten (z.B. über Sockets, NamedPipes oder auch WCF), je nach Anwendungsfall auch mit "Nutzlast" (also irgendwelchen Werten). Deine Events solltest Du schon über diese Wege feuern und abfangen, Deine Idee vom gemeinsamen wird wohl so nicht funktionieren.

[Klotzkopp]

Unter Shared Memory verstehe ich einen Speicherbereich auf dem beide Prozesse Zugriff haben. Und wenn ich dann ein Objekt in diesem Speicherbereich ablege dann sollen beide Prozesse auch auf die selbe Speicheradresse zugreifen wenn diese auf das Objekt zugreifen.

Aus dem Beispielcode sollte doch klar werden, dass der Shared Memory nur zum Serialisieren benutzt wird. Das ist wirklich nur roher Speicher, .NET-Objekte können da drin nicht leben. Wenn du ganze Objekte übertragen willst, musst du einen High-Level-Mechanismus wie Remoting benutzen.

[Gateway_man]

Danke euch. Sehr schade das es nicht anders möglich ist.

Ich hatte mir für den worst case schon was überlegt aber das kostet mich mindestens zwei Wochenenden und sehr viel Redbull.

Ich werde Named Pipes nutzen und mir eine Bibliothek schreiben in der ich Objekte anhand von TypeID und InstanceID registriere.

Jedes dieser Objekte muss von Der Basis Klasse erben und wenn ein Objekt intern ein Event wirft werden die EventArgs sowie der Sender deserialsiert und automatisch über die Named Pipes an Clients geschickt die sich für dieses Event beim Server registriert haben.

Das soll dann natürlich nicht nur bei Events funktionieren, sonder auch bei Properties und Funktionen.

Gibt es eigentlich eine Möglichkeit beim öffnen eines Named Pipe Server zwischen den verbundenen Clients zu unterscheiden? Seit dem .NET 3.5 gibt es ja eine eigene .NET Implementierung und bei den beispielen die ich gesehen habe ist mir aufgefallen das Nachrichten nie direkt an einen Client sondern immer an alle verbundenen Clients geschickt werden.

Lg

Gateway