Singleton in seperaten AppDomains
Hallo zusammen,
ich habe mich am Wochenende mit einem Problem der besondern Art rumgeärgert, und zu keiner Lösung gekommen.
Aber lasst mich erstmal erklären: Es geht um eine Simulation namens rFactor.
Sie hat eine Plugin architektur mit native dll´s. Ich hatte die idee, ein plugin dafür zu schreiben, um über .NET damit zu arbeiten.
Weil ich es state of the art machen wollte und auch c++ programmiere bin, hatte ich die idee das in c++/cli zu machen, quasi eine gemischt dll. Damit habe ich auch schon erfahrung und das klappt auch soweit. telemetry daten werden in die native seite der dll eingeseist, und in einem beispiel projekt in c# kann ich auf die manged typen zugreigen, die ich in der dll implementiert habe.
jetzt habe ich aber ein kleines architektur proble. die simulation speist die daten auf der einen seite in die dll ein, und ich widerum will von der anderen seite drauf zugreifen. ich habe dann die managed klasse einfach als singleton implementiert.
die unmanaged seite schiebt die daten in den managed singleton, und die c# anwednung holst sie wieder raus. so sollte es jendenfalls sein! das problem ist aber, das die c# anwednung nicht die gleiche instanz des singleton nutzt wie die simulation.
jede seite hat quasi ihre eigene instanz, weil ja qausi aus 2 verschiedenen prozessen aus operiert wird. hat einerne idee wie man das lösen kann? oder einen besseren vorschlag am gesamt system?
moin
wie wäre es mit einer Datei zum Datenaustausch
oder besser noch über einen TCP Stream
mfg
Datei ist denke ich zu langsam. tcp stream habe ich auch chon dran gedacht.
noch andere vorschläge?
Lol, aufforderung nachkommen? bin ich hier beim bund oder was? krieg ich haue wenn ichs nicht mache? schreib was zum thema oder änder den titel selbst.
wenns dir nicht passt, lösche es!
das diese forum mods immer meinen die müssten einen auf dicke hose machen...
@sixpack
Entschuldige mal aber geht das ganze auch freundlicher ?
Ich glaube wenn du so weiter machst wirste Problemem bekomen das deine zukünftigen Fragen weiterhin beantwortet werden
mfg
Original von Sixpack
Lol, aufforderung nachkommen? bin ich hier beim bund oder was? krieg ich haue wenn ichs nicht mache? schreib was zum thema oder änder den titel selbst.
wenns dir nicht passt, lösche es!das diese forum mods immer meinen die müssten einen auf dicke hose machen...
- nein kein bund
- nein keine haue, aber was anderes
- nein ich ändere ihn jetzt erst recht nicht
- ja löschen wäre ne Idee
- ist nicht auf dicke hose machen, sondern es wurde einfach nur ein hinweis an dich gegeben. du willst ihn nicht umsetzen, also gut!
Original von blackcoin
Ich glaube wenn du so weiter machst wirste Problemem bekomen das deine zukünftigen Fragen weiterhin beantwortet werden
dem kann ich mich nur anschließen!!
Das war lediglich ein Hinweis, wie du die Chance erhöhst, das jemand überhaupt deinen Beitrag ließt, und dir dann entsprechend helfen kann. Ich persönlich hab auch keine Lust mich da durchzuarbeiten. Wenn das Lesen der Frage einfach etwas weniger quälend ist, bekommst du auch mehr, schneller und bessere Antworten.
Aber wenn dich das nicht interessiert, zwingt dich auch keiner die Hinweise zu befolgen.
e.f.q.
Aus Falschem folgt Beliebiges
Wie dem auch sein, so ein ähnliches Problem habe ich auch (noch immer). Siehe Single Instanz einer DLL
Ich verwende derzeit .NET Remoting als Lösung. Aber allzu glücklich bin ich mit dieser Lösung nicht(Port muss frei sein und es muss ein Server vorhanden sein). Falls da noch jemanden etwas einfallen sollte, so würde ich mich auch sehr freuen.
lg
Georg
Es gib in C# ein Schlüsselwort das "angeblich", laut MSDN, ein variable Prozessübergreifend im Betriebssystem zur Verfügung zu stellen um sie u.a. in Singletons zu verwenden. Es nennt sich volatile. Keine Ahnung ob es geht, bzw. wie. Hab nur davon gelesen.
Deshalb auh ->
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo kleines_eichhoernchen!
Das Schlüsselwort volatile sagt dem Compiler nur, dass die Variable von außen(Hardware, Betriebssystem, anderer Thread) verändert werden kann. Deshalb wird eine solche Variable nie zwischen gespeichert, sondern immer der aktuelle Wert gelesen/geschrieben.
achso... jetzt weiß ichs auch... dann kann ich leider nich helfen. ja über remoting gehts, bzw. üder mutexxe lässt sich das thread sicher gestalten
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
@nils
mir gefiel nur der befehlston nicht, kein grund unruhig zu werden... 😉
@topic
nach einigen rechernchen denke ich nun das remoting wohl die einzige möglichkeit darstellt das problem zu lösen.
welche erfahrung habt ihr mit der performance?
es sind viele daten (telemetry halt) die jede sekunde refreshed werden.
wenn das plugin langsam wird, wird die ganze simulation langsamer 🙁
Ich hab mit Managed C++ noch nicht sonderlich viel gemacht und bin etwas darüber verwundert wie das wohl läuft.
Hast du die andere AppDomain selbst erstellt, oder baut es die automatisch als Trennwand zwischen managed und unmanaged?
Letzteres ist dann doch recht kompliziert zu handhaben, da wirst du wohl Remoting benutzen müssen. Performancemäßig müsste da der IPC Channel mit BinaryFormatter noch am Besten sein.
Wenn du die AppDomain aber selbst erstellst, was ja bei Plugins auch üblich ist, gibt es leichtere Wege.
Ganz prinzipiell brauchst du ja nur ein MarshalByRefObject auf der "anderen" Seite, was dir die Instanz von dem "Singleton" (was ebenfalls MarshalByRefObject erben muss) liefert. Bei selbsterstellter AppDomain ist es ja ganz leicht soetwas einzuschleusen.
e.f.q.
Aus Falschem folgt Beliebiges
Ich kann mich dunkel entsinnen, dass irgendjemand hier mal ein AddDomain-übergreifendes Singleton via Remoting gebastelt hat...
Original von Sixpack
@nils
mir gefiel nur der befehlston nicht, kein grund unruhig zu werden... 😉....
hallo Sixpack,
sorry von meiner Seite, wenn das so rüberkam.
sollten wirklich nur Hinweise sein, zum befehlen bin ich wirklich nicht hier. (dafür ist ja die bundeswehr da) 😉
Thema geklärt.
nils
Also selbst erstelle ich die AppDomain nicht!
Es ist ja so, das die native seite ein plugin von einer fremden applikation ist.die managed seite nehme ich als einstiegspunkt für meine applikation.
das native plugin soll dan die daten in den managed singleton schieben. das klappt ja auch, aber wenn ich von der anderen seite komme hab ich hlt nen anderen singleton, was ja eigentlich auch logisch ist! ich guck mir das mal mit remoting an, das habe ich zwar noch nie gemacht, aber sowas nehme ich immer als gute übungen, so lernt man am besten draus denke ich!
und zum thema maneged c++
ob managed c++ oder c#, es ist ja nur die syntax anders. gibt zwar paar besinderheit(gemischer code, pointer...) aber als alter c++ programmiere ist das ok!
remoting 2.0 stellt einen sogenannten IPC-Kanal zur Verfügung. Dieser dient der lokalen Interprozess-Kommunikation und ist verdammt schnell, da alles lokal im Hauptspeicher abgewicklet wird. Intern wird das Named Pipes-Protokoll eingesetzt.
Stichwort für Forumssuche: IpcChannel
Mit Remoting lassen sich doch alle Klassen "austauschen" prozessübergreifend, in unterschiedlichen AppDomains und zu anderen Kompostern übertragen, die von der Klasse MarshalByRefObject geerbt haben. (Ich hab heut schon wieder ein deutsch...)
Da könnte man ja auch eine Datei (FileStream) im Netzwerk bearbeiten, also das verschiedene Leute gleichzeitig lesen und schreiben können? Ginge das?
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hervorragend! IPC scheint genau das zu sein was ich brauche! Mich hat nämlich am Remoting der ganze Netzwerk Krempel gestört, weil es für meine Zwecke ein Overhead ist, da ich physikalisch auf den gleichen Computer bleibe.
Danke Rainbird!!!! 👍