thread-unsichere, native Bibliotheken

[KrokoDiehl]

Hallo zusammen.

Ich habe ein Problem mit Java und nativen Bibliotheken. Das Problem ist ziemlich betriebssystemnah (...glaube ich...) und betrifft ein Thema, in dem ich mich nicht sehr heimisch fühle.

Folgende Situation:
Ich habe einige C-Bibliotheken die schon recht alt sind und NICHT threadsicher sind, sprich u.a. globale Variablen haben. Diese auszubessern ist aber erstmal keine Option... (es wäre auch ein Heidenaufwand).
Diese "darf" ich aus einer Java-Anwendung heraus aufrufen. Das ist erstmal kein Problem. Ich habe das bisher über JNI und

System.loadLibrary()

gemacht und es läuft auch.

Aber das konkrete Problem: Wenn ich meine Java-Anwendung mehrmals instanziieren will, geht das nicht, weil dies aus Sicht des Betriebssystem (BS) immernoch der gleiche Prozess ist und dieser die native Bib. schon dazu geladen hat. Sprich es wird nicht ein zweites mal neu geladen. Damit tun die nativen Bibs. aber nicht, weil sie sich eben (v.a. wegen der Globalen) überschneiden. Ich hab's getestet, das Ganze schmiert recht schnell mit einer Speicherschutzverletzung ab
Bisheriger Workaround: Es wird immer ein neuer Javaprozess (

Runtime.exec()

...) gestartet, sodass die Bib. immer neu geladen wird. Das ist aber schlecht, weil ich a) zwei separate Prozesse hab und dazwischen nur schwer kommunizieren kann (Thema IPC) und auch zwei separate VMs (und u.A. mehr Speicherverbrauch).

Nun meine Fragen: Gibt es eine Möglichkeit, innerhalb einer VM ein Java-Programm mehrmals separat auszuführen, sodass das Laden einer nativen Lib. auch mehrmals möglich ist? Oder geht es z.B. gar nicht, weil dies eben eine Sache vom BS ist (habe es bisher unter Windows NT und Linux getestet).

Oder wisst ihr irgendwie Suchbegriffe, Literatur, ... irgendwas mit dem ich meine Suche mal fortsetzen kann, weil bisher bin ich auf dem Standpunkt geht nicht anders.

Also danke für eure Zeit.

 

[FArt]

Ich habe ein Problem mit Java und nativen Bibliotheken. Das Problem ist ziemlich betriebssystemnah

lol.. ja, das haben native Bibliotheken so an sich...

Eine VM wird die Library meines Wissens nur einmal laden, weil der Prozess ja die Library verwendet...

Evtl. ist es möglich, alle Zugriffe aus der VM auf die Library zu synchronisieren, z.B. über den selben Mutex. Das ginge relativ einfach, wenn die Zugriffe auf die Library nicht kreuz und quer im Code verstreut sind, sondern z.B. über einen Wrapper getätigt werden. Wenn das nicht der Fall ist, könnte man evtl. noch über AOP Mittel eine Synchronisierung hinbekommen. Aber auch da muss man angeben können, wo man einen Eingriff für die Synchronisierung durchführen möchte.

 

[KrokoDiehl]

Danke für die Rückmeldung.
Das Problem ansich ist aber nicht die Synchonisation der Aufrufe, sondern das was diese Bibliothek intern macht. Sie speichert ihre Zustände z.B. in globalen Variablen. Sobald ich aber eine neue Instanz erstelle, wird zwar meine Java-Seite neu instanziiert, diese Bib. aber bleibt die gleiche (weils der gleiche Prozess ist), insbesondere auch deren Globalen. Also intern ist nichts mehr mit verschiedenen Zuständen

Zu Beginn hatte ich ja die Hoffnung, dass dieses einfach durch folgendes lösbar wäre:

class MyNativeLibraryWrapper
{
    // dies wird einmal für alle MyNativeLibraryWrapper ausgeführt
    static {
        System.loadLibrary("myNativeLibrary");
    }    
}
// versus
class MyNativeLibraryWrapper
{
    public MyNativeLibraryWrapper()
    {
        // dies wird einmal pro Instanz gemacht... wäre cool wenn es auch die Bib. immer neu
        // laden würde, aber das wäre naiv (und in 99% aller Fälle eh nicht erwünscht)
        System.loadLibrary("myNativeLibrary");
    }
}

 

[Empire Phoenix]

Nicht sicher ob es geht, aber wenn du über eine der Betriebsystem functionen die Bibliothek dynamisch entladen würdest, und danach wie oben neu laden müsste das dann klappen? Jetzt ist die frge wie man dynamisch entläd:
DLL entladen... - Entwickler-Forum
klingt alles andere als spaßig, evtl doch zwei prozesse nehmen? wobei der eine die dll läd und jedesmal neugestartet wird?

 

[FArt]

Es geht um Zustände zwischen mehreren Calls? Das hat aber nichts mit Threadsicherheit zu tun, wie es in deinem ersten Posting steht sondern mit Zuständen.
Ergebnis: das wird nicht gehen.

 

[KrokoDiehl]

Hallo.
Ok, ich fasse zusammen, dass mein Vorhaben mit den aktuell vorhandenen, thread- UND zustandsunsicheren nativen Bibliotheken nicht funktioniert, bzw. nur über jeweils neue Prozesse.
Der Ansatz von Empire Phoenix zeigt zwar, dass man theoretisch hier herumhacken kann, aber darauf möchte ich mich nicht begeben

Eine weitere Frage in dem Kontext:
Ich habe eine Java-Anwendung, die ich via

java -cp ... pak1.pak2.MyMainClass

starte. Sprich ohne weitere Parameter für die JVM. Dieser Prozess heißt "java.exe" (in Windows) und hat ~20K Speicher, hauptsächlich wegen der JVM.
Das ist soweit kein Problem.

Aus dieser Anwendung heraus starte ich nun aber neue Java-Prozesse mittels

Runtime.getRuntime.exec("java pak1.pak2.MyOtherMainClass");

Geht auch wunderbar. ABER es erzeugt eben jeweils eine neue "java.exe" mit ~20K Speicher weil es eine neue JVM startet.
Gibt es hier eine Möglichkeit beide Java-Anwendungen in der gleichen JVM zu haben? Ich gebe zu, mit den JVM-Parametern habe ich mich bisher kaum beschäftigt, aber dass was ich probiert habe (Server-VM, Client-VM, Shared Mode, Mixed Mode, ...) hat hier nichts bewirkt.

 

[FArt]

Natürlich kann man die beiden auch in einer VM laufen lassen: durch Aufruf der main-Methode der zweiten Applikation.
So aber die Theorie, die selten sinnvoll eingesetzt werden kann.

Ein System.exit() der zweiten Applikation beendet auch die "Hauptapplikation", die beiden Applikationen teilen sich statische Ressourcen, außer man hantiert auch noch mit Classloadern herum, die sowieso nötig werden, wenn sich die Klassenpfade der Applikationen stark unterscheiden usw.

Praktisch ist das also möglich, aber sehr aufwendig und nicht wirlich schön.

 

[anonym]

Ja, gibt es. Die "einfachere" ist, über einen JarClassLoader die Jar- Datei(en) der zweiten Anwendung zu laden und die main()- Methode der Main-Class aufzurufen.

Die kompliziertere ist aus beiden Jars OSGi- Bundles zu machen und dann das Bundle zu laden und zu starten.

Btw: Kann es sein, dass OSGi automatisch die DLL zweimal laden würde? Auf diesem Weg also ohne viel gehacke sein erstes Problem zu lösen wäre? Das hängt vermutlich von der OSGi- Implementierung ab, ich kenne mich leider nicht gut genug aus, um das zu beurteilen.

 

[KrokoDiehl]

Das sind schonmal nette Ideen zum Weitergooglen. Danke soweit

 

[FArt]

Ja, gibt es. Die "einfachere" ist, über einen JarClassLoader die Jar- Datei(en) der zweiten Anwendung zu laden und die main()- Methode der Main-Class aufzurufen.

Das hört sich nur einfach an, ist aber alles andere als einfach.

Btw: Kann es sein, dass OSGi automatisch die DLL zweimal laden würde? Auf diesem Weg also ohne viel gehacke sein erstes Problem zu lösen wäre? Das hängt vermutlich von der OSGi- Implementierung ab, ich kenne mich leider nicht gut genug aus, um das zu beurteilen.

Die DLL wird vom Betriebssystem verwaltet. Sie sind genau dazu da, dass sie von mehreren Applikationen gleichzeitig verwendet werden, auch wenn das mit neueren Windosen etwas anders aussieht. Somit kann ich mir nicht vorstellen, dass man das über Javamittel beeinflussen können soll. Aber auch ich bin ja lernfähig ;-)

 

[anonym]

Das hört sich nur einfach an, ist aber alles andere als einfach.

Deshalb ja die Anführungszeichen

Die DLL wird vom Betriebssystem verwaltet. Sie sind genau dazu da, dass sie von mehreren Applikationen gleichzeitig verwendet werden, auch wenn das mit neueren Windosen etwas anders aussieht. Somit kann ich mir nicht vorstellen, dass man das über Javamittel beeinflussen können soll. Aber auch ich bin ja lernfähig ;-)

Meine Idee war, dass OSGi ja bei JARs dependency- Entkopplung betreibt, also für jedes Bundle einen eigenen Classpath hat. Das würde ja für Dlls auch Sinn machen.
Aber nachdem ich gesehen habe, wie der Link von Empire Phoenix DLLs los wird, nehme ich das zurück. Mit DLLs scheint das nur auf Betriebssystemebene möglich zu sein.

 

[Empire Phoenix]

wenne snur eine .exe gibt wird die dll nur einmal geladen, sogesehen MUSST du zwei jvms nehmen, und die eine halt ab und zu neustarten zum zurücksetzten der zustände (bzw, x wenn du die zustände noch brauchst, und die dann abschiessen wennse nicht mehr benötigt werden)

Als hinweis sei mal der security task manager genannt, der dir geladene dlls anzeigen kann, dann kannste sehen was die wohin lädt. Und demnach beurteilen was mehrfach vorhanden sein muss um die dll mehrfach zu haben.