nur eine Instanz für mehrere DLL-Ladevorgänge?



  • Hallo,

    ich würde gern eine DLL von mehreren Programmen laden. Dabei soll allerdings nicht bei jeden Ladevorgang eine neue Instanz erzeugt werden, sondern eine globale Instanz dieser DLL benutzt werden. Ist sowas möglich?

    Sid



  • das macht das betriebssystem sowieso.



  • ad231 schrieb:

    das macht das betriebssystem sowieso.

    Bei mehreren Prozessen wird nur der Programmcode gemeinsam genutzt, nicht aber das Datensegment.



  • sri schrieb:

    ad231 schrieb:

    das macht das betriebssystem sowieso.

    Bei mehreren Prozessen wird nur der Programmcode gemeinsam genutzt, nicht aber das Datensegment.

    schlaubi schlumpf lässt grüßen



  • Wo hast Du das Problem? Das System macht das völlig allein. Haben die anderen auch gesagt! :p



  • Also nochmal: ich möchte eine DLL von mehreren Programmen laden, dabei soll nur EINE globale Instanz erzeugt werden. Mir ist klar das der Programmcode einer DLL nur einmal in den Speicher geladen wird. Allerdings bekommt ja jeder Prozess seine eigene Instanz (jeder DLL-Aufruf bekommt sein eigenes Datensegment, wie sri schon richtig schrieb)

    http://de.wikipedia.org/wiki/Dynamic_Link_Library#DLLs_im_Speicher



  • Dann mach das Datensegment halt shared 🙄 Ich sag dir jetzt schon dass das keine gute idee ist aber die leute in diesem forum sind ja sowieso unbelehrbar


  • Mod

    Du kannst Teile Deinr Daten als Shared Memory ablegen.
    Aber der Speicherzugriff muss dann synchronisiert werden, weill eben mehrere Threads gleichzeitig zugreifen können.

    Aber mal eine ganz andere Frage:
    Was soll das für einen Sinn haben "EINE globale Instanz" zu haben?

    Ist ein COM-OutOfProc-Singleton da nicht evt. die bessere Lösung?



  • Also der Hintergrund ist:
    die DLL stellt eine Schnittstelle für ein Gerät dar, welches nur exklusiv angesprochen werden kann(Funktionen: Öffnen, Schliessen, Lesen, Schreiben).

    Mein erster Ansatz war zB:
    Prog A: Prog B:

    Schleife{ Schleife{
    Öffnen Öffnen
    Lesen/Schreiben Lesen/Schreiben
    Schliessen Schliessen
    } }

    Problem: Synchronisation, Performance(Öffnen&Schliessen)

    zweiter Ansatz mit einer "globalen" DLL-Instanz:

    Prog A Prog B
    Öffnen(falls noch nicht geöffnet) Öffnen(falls noch nicht geöffnet)
    Schleife{ Schleife{
    Lesen/Schreiben Lesen/Schreiben
    } }
    Schliessen Schliessen

    Problem: Schliessen/Öffnen muss synchronisiert werden (das "erste" Prog muss Öffnen, das "letzte" Prog muss Schliessen)Lesen/Schreiben muss synchronisiert werden

    Vielleicht gibts ja noch eine elegantere Lösung 🙂



  • Problem: Schliessen/Öffnen muss synchronisiert werden (das "erste" Prog muss Öffnen, das "letzte" Prog muss Schliessen)Lesen/Schreiben muss synchronisiert werden

    Referenz Counting verwenden (wie WinSock o.ä.).



  • ad231 schrieb:

    Dann mach das Datensegment halt shared

    Soviel zum Thema

    ad231 schrieb:

    das macht das betriebssystem sowieso.



  • Hi sid_vicious,

    so wie Du Dein Problem beschrieben hast, kannst Du die gleiche Vorgehensweise wie beim Öffnen und Schliessen von seriellen Schnittstellen (COM-Ports) machen.

    Sobald ein Programm ein COM-Port erfoglreich geöffnet hat (z.B. COM2), bekommt ein anderes Programm beim gleichen Versuch eine Fehlermeldung und muß warten und zu einem späteren Zeitpunkt wiederholen oder eine andere COM-Port Nummer wählen.

    Dieser COM-Port wäre dann in Deinem Fall Deine DLL, welche eben Dein Gerät anspricht.
    Dafür braucht man keine Shared-Memory oder gar Instanz-Tricksereien.

    (Ich hoffe, ich habs so richtig verstanden? )

    Martin


  • Mod

    Oder man zentralisiert das ganze mit einem eigenen Prozess, der dieses ganze Geschichte verwaltet.

    Out Of Proc COM Server, oder gar Sevice, oder simpler eigener Prozess mit entsprechnem IPC.



  • sri schrieb:

    ad231 schrieb:

    Dann mach das Datensegment halt shared

    Soviel zum Thema

    ad231 schrieb:

    das macht das betriebssystem sowieso.

    ja du idiot, weil kein mensch so einen mist machen wollen würde, eine gesamte dll und alle ihre datensegmente betriebssystemweit zu sharen. lies mal ein buch über OS grundlagen du verpennter vollpfoste. rofl.- 👎



  • @Mmacher:
    Ja im Prinzip funktioniert es so wie von Dir beschrieben. Ich möchte nur vermeiden das die Schnittstelle dauernd geöffnet und geschlossen wird. (Perfomance)
    Besser wäre ein System wo die Schnittstelle "on demand" geöffnet/geschlossen werden kann und von allen Programmen ohne viel Overhead mitbenutzt werden kann.

    Ein Szenario wäre zum Beispiel:
    Ein Programm braucht die Schnittstelle um Daten zu versenden.
    Ein anderes Programm ist ein Schnittstellenlogger, der die Aufgabe hat den Datenverkehr mitzuloggen.

    @Martin Richter
    Der COM Server klingt sehr interessant. Könntest Du den mal etwas genauer erklären? Wo find ich da einen guten Einstieg(Literatur, Tutorials)?

    Dein Vorschläge COM/Service/Prozess würden aber darauf hinauslaufen das es eine eigenständige Applikation wird?!


  • Mod

    sid_vicious schrieb:

    Der COM Server klingt sehr interessant. Könntest Du den mal etwas genauer erklären? Wo find ich da einen guten Einstieg(Literatur, Tutorials)?

    MSDN? ATL Internals, Essential COM, VC-Wizads 😉

    sid_vicious schrieb:

    Dein Vorschläge COM/Service/Prozess würden aber darauf hinauslaufen das es eine eigenständige Applikation wird?!

    Ja!



  • ad231 schrieb:

    ja du idiot, weil kein mensch so einen mist machen wollen würde, eine gesamte dll und alle ihre datensegmente betriebssystemweit zu sharen. lies mal ein buch über OS grundlagen du verpennter vollpfoste. rofl.- 👎

    Schlaubi, lass es gut sein. Genau darum ging es in seiner Frage.



  • sid_vicious schrieb:

    Ich möchte nur vermeiden das die Schnittstelle dauernd geöffnet und geschlossen wird. (Perfomance)

    Richtig.

    sid_vicious schrieb:

    Besser wäre ein System wo die Schnittstelle "on demand" geöffnet/geschlossen werden kann und von allen Programmen ohne viel Overhead mitbenutzt werden kann.

    Ein Szenario wäre zum Beispiel:
    Ein Programm braucht die Schnittstelle um Daten zu versenden.
    Ein anderes Programm ist ein Schnittstellenlogger, der die Aufgabe hat den Datenverkehr mitzuloggen.

    Vorneweg: Dieses Vorhaben über einen einzigen "Standard"-COM-Port zu realisieren ist zum Scheitern verurteilt.
    Denn ein COM-Port kann nur von einer einzigen Instanz (also Prozeß bzw. Programm) zur gleichen Zeit genutzt werden. Also müssen andere Lösungswege her.

    (Ist der Schnittstellenlogger von Dir programmiert oder eine fertige Software?)

    Folgende Alternativ-Möglichkeiten fallen mir gerade ein:
    A) Du baust (programmierst) in Deiner Applikation den Schnittstellenlogger selbst ein -> So können 2 Funktionen im selben Prozeß (Instanz) auf einen COM-Port zugreifen.

    😎 Von Sysinternals (jetzt Microsoft) gibt es das Tool PortMon http://technet.microsoft.com/de-de/sysinternals/bb896644.aspx . Es protokolliert alle Vorgänge auf einem COM-Port im Hintergrund, und schreibt auf Wunsch auch in eine Datei. Vielleicht kann es Deinen Schnittstellenlogger ersetzen? (Funktionsweise: PortMon wendet auf Treiber-Ebene die Filter-API- und IOCTL-Funktionen an)

    C) Du programmierst einen COM-Port-Redirector oder -Splitter. Das ist eine Treiber-Software, welche die Daten von z.B. COM1 auf einen anderen virtuellen COM-Port z.B. COM5 "kopiert". D.h. Deine Applikation greift auf COM1 zu, die andere Applikation (Datenlogger) auf COM5, aber beide greifen auf den ein- und dasselben RS232-Hardware-Port zu. Das setzt einige Kenntnisse und Erfahrung voraus, da teilweise im Kernel-Mode (ich selbst habe sowas aus Zeitgründen noch nicht gemacht).

    D) Besorg Dir einen solchen fertigen (kostenpflichtigen) COM-Port-Redirector oder -Splitter, z.B. von http://www.eltima.com.

    Martin



  • [Nachtrag:]

    Alternativ-Möglichkeit E):
    Du verwendest 2 oder 3 serielle Ports, je nachdem ob der Schnittstellenlogger von beiden Richtungen oder nur eine Richtung mitloggen muß.:
    Applikation verwendet COM1
    Schnittstellenlogger verwendet COM2 und COM3.
    An den Schnittstellen brückst Du die Leitungen von COM1 auf COM2 und COM3.

    Martin



  • @Martin
    Danke für deine Antwort. Also bei der Schnittstelle handelt es sich nicht um einen COM-Port. Sry falls das falsch rübergekommen ist 😉
    Es ist ein USB2CAN Schnittstellenwandler. Im Prinzip hab ich vom Hersteller eine DLL die ich benutzen kann. Leider kann man die nur exklusiv für ein Programm benutzen.(oder eben mit Öffnen/Übertragen/Schliessen)
    Deshalb möchte ich gern eine Wrapper-DLL drumschreiben, sodass auch mehrere (selbstgeschriebene)Applikationen darauf Zugriff haben.


Log in to reply