Meine C # -Anwendung verwendet nativen Code, der nicht Thread-sicher ist.
Ich kann mehrere Prozesse dieses nativen Codes ausführen, indem ich die Kommunikation zwischen Prozessen nutze, um Parallelität zu erreichen.
Meine Frage ist, kann ich stattdessen App Domains verwenden, so dass mehrere verwaltete Threads, jeder in einer anderen App Domain, den nativen Code aufrufen und sich nicht gegenseitig stören?
Das Hauptziel ist es, eine Prozesstrennung zu verhindern.
Ja es kann getan werden, aber Sie sollten ernsthaft messen, ob der Aufwand durch Vorteile zurückgezahlt wird.
Windows lädt nicht mehrere Kopien einer nicht verwalteten DLL, und nicht verwaltete DLLs werden pro Prozess geladen (nicht pro AppDomain ). Was Sie tun können, ist mehrere temporäre Kopien derselben DLL zu erstellen und dann mit LoadLibrary() zu laden.
Jeder wird pro Prozess geladen, aber sie werden voneinander getrennt (so dass sie Thread-sicher sind). All diese Dinge können innerhalb einer Klasse gebunden werden, die nicht verwaltete Aufrufe umschließt ( LoadLibrary , FreeLibrary , GetProcAddress und Aufruf selbst). Es verbraucht weniger Ressourcen und ist schneller als mehrere Prozesse, aber Sie müssen DllImport usage ablegen.
Der einzige Vorteil, den ich sehe, ist, dass diese viel besser skaliert werden kann als mehrere Prozesse (weil sie weniger Ressourcen verbraucht), wenn Sie Instanzen wiederverwenden, die einen Cache behalten (es ist schwieriger, einen Prozess-Cache als einen Objekt-Cache zu behalten). p>
Nein, AppDomains sind ein reines Managed-Code-Konzept. Es erreicht Isolation, indem die verwurzelten Objektstämme getrennt bleiben. Eine AppDomain kann die Objekte eines anderen Objekts nicht sehen, sodass das Abbrechen von Code und das Entfernen von Assemblys sehr sicher ist. Nie ein Unfall, es wirft alle Daten weg, die Staat enthalten könnten.
Nicht verwalteter Code ist völlig agnostisch für den GC-Heap und daher für AppDomains, das er in seinem Datenabschnitt und seinem eigenen nativen Heap (HeapAlloc) zuordnet. Solche Zuweisungen sind prozeßglobal. Dies macht einen Prozess zur Isolationsgrenze, Sie benötigen einen Hilfsprozess, der die DLL lädt und mit einem der .NET-Prozess-Interop-Mechanismen (Socket, Named Pipe, Memory-Mapped-Datei, Remoting, WCF) kommuniziert. p>
Technisch könnten Sie Kopien der DLL erstellen, jede mit einem anderen Namen. Aber das skaliert sehr schlecht und der Pinvoke ist sehr peinlich, da man [DllImport] nicht mehr benutzen kann. Sie benötigen eine Delegatendeklaration für jede exportierte Funktion und LoadLibrary () und GetProcAddress (), um die Delegatobjekte zu initialisieren.
Tags und Links .net c# multithreading native appdomain