Hallo.

Ich verwende zum Verhindern von 2 Programminstanzen derzeit folgenden Code: http://www.delphipraxis.net/internal_redirect.php?t=136 .

Dieser hat eigentlich immer gut seine Dienste erfüllt, jedoch bin ich jetzt auf ein Problem gestoßen.

Ich arbeite an einem Programm, das mit dem System startet und eine Datei ständig liest und schreibt. Es ist nur 1 Programminstanz erlaubt. Läuft eine Weitere, kommen sich die Instanzen durch die Lese/Schreibzugriffe sowie den Berechnungen dazwischen in die Quere und es kann zu Fehlern (auch Datenfehlern durch Fehlberechnungen) kommen.

Das Problem besteht bei der Benutzerumschaltung von Windows. Loggt man sich als 2ter Benutzer gleichzeitig ein, kann das Programm Problemlos mit dem Autostart hochgefahren werden - die Instanzprüfung via Mutex'es läuft nur auf Benutzerebene, nicht auf Systemebene.

Gibt es eine systemglobale Alternative zu den Mutex? Wenn ja, ist diese dann dem anderen Code vorzuziehen?

Ich persönlich würde stets dazu tendieren, immer die Instanz systemglobal anstelle benutzerlokal zu sperren, sobald das Programm Daten aus einer bestimmten Datei liest und schreibt. Es könnte ja ansonsten passieren, dass sich die Leseprozesse und Schreibprozesse durch Zufall überkreuzen (sofern eine Instanz des anderen Benutzers die Datei z.B. updated und somit für längere Zeit in diese schreibt). Eure Meinung?

Gruß
blackdrake

warum öffnest du nicht die Datei exklusiv und prüfst das ggf. beim starten einer weiteren Instanz?
ggf. kannst du ja eine separate Datei erstellen und beim beenden löschen.

HTH Frank

Zitat von _frank_:

warum öffnest du nicht die Datei exklusiv und prüfst das ggf. beim starten einer weiteren Instanz?
ggf. kannst du ja eine separate Datei erstellen und beim beenden löschen.

HTH Frank

Exklusives Öffnen: Habe ich mir auch schon mal überlegt. (Eventuell habe es auch mal in einem anderen Projekt implementiert? Werde ich nochmal nachschauen.) Das Problem ist, dass die 2te Instanz zumindestens eine Meldung ausgibt, wenn es zu einem Schreibfehler kommt.

Beim Starten prüfen: Das ist ja genau das Problem. Der zweite Benutzer des Systems sieht nicht, wenn der erste Benutzer eine Mutex hat. Also kann ich schlecht auf eine Zweitinstanz prüfen.

Die separate Datei wäre dann ein Lockfile. Sowas wird meines Wissens bei Linux-Servern (Apache) verwendet, jedoch ist dies für Client-Software bedenklich, da die Software unbrauchbar wird, wenn man sie durch Stromausfall oder den Taskmanager beendet. (Unter der Annahme, der DAU Benutzer weiß nicht, dass eine Lockfile gelöscht werden muss)

Wie wäre es mit Named Pipes oder MM-Files?

Zitat von blackdrake:

Exklusives Öffnen: Habe ich mir auch schon mal überlegt. (Eventuell habe es auch mal in einem anderen Projekt implementiert? Werde ich nochmal nachschauen.) Das Problem ist, dass die 2te Instanz zumindestens eine Meldung ausgibt, wenn es zu einem Schreibfehler kommt.

Beim Starten prüfen: Das ist ja genau das Problem. Der zweite Benutzer des Systems sieht nicht, wenn der erste Benutzer eine Mutex hat. Also kann ich schlecht auf eine Zweitinstanz prüfen.

Die separate Datei wäre dann ein Lockfile. Sowas wird meines Wissens bei Linux-Servern (Apache) verwendet, jedoch ist dies für Client-Software bedenklich, da die Software unbrauchbar wird, wenn man sie durch Stromausfall oder den Taskmanager beendet. (Unter der Annahme, der DAU Benutzer weiß nicht, dass eine Lockfile gelöscht werden muss)

nicht nur die datei anlegen, sondern auch gegen Zugriff durch andere Prozesse sperren (Exklusiv öffnen halt ), ist imho das gleiche wie Memory-Mapped-Files...und dann schauen, ob die datei gesperrt ist. ist der prozess tot kann die datei geöffnet werden und die "2. Instanz" ist erlaubt.

siehe dwShareMode in [MSDN] CreateFile
den Wert auf 0 setzen sollte das bewerkstelligen. wie du testen kannst, steht auch drin

Gruß Frank

Zitat von blackdrake:

Gibt es eine systemglobale Alternative zu den Mutex?

Es gibt systemglobale Mutexe (mit dem Präfix "Global\").
Wird nur nicht von allen Windows-Versionen unterstützt (deren Support längst ausgelaufen ist).

-Bei start prüfen ob der Prozess läuft (Prozessliste abgreifen gucken ob 2 Einträge drinn sind).

ODER

-Das System richtig benutzen, d.h. die Datei die den Konflikt verursacht in den Ordner Eigene Dateien legen-

ODER

-(InterProcessCommunication)IPC Clientstarten,nach IPC Server fragen, wenn der fehlt dann selbst IPC-Server starten.

Was ist denn gegen einen globalen Mutex einzuwenden?

markieren

Delphi-Quellcode:

initialization
  hApp := CreateMutex(nil, True, 'Global\MYAPP');
  if GetLastError = ERROR_ALREADY_EXISTS then
  begin
    MessageDlg('Die Software kann nur einmal gestartet werden!', mtError, [mbOK],0);
    Halt;
  end;

finalization
  if hApp <> 0 then CloseHandle(hApp);

Edit: Da dieser Code ja für die Lib vorgeschlagen wurde ein Nachtrag.
Das Handle sollte beim Beenden natürlich wieder freigegeben werden

Zitat von QuickAndDirty:

Bei start prüfen ob der Prozess läuft (Prozessliste abgreifen gucken ob 2 Einträge drinn sind).

Der jeweilige Benutzer hat möglicherweise nicht die Rechte, um alle Prozesse aufzulisten, bzw. deren relevate Eigenschaften zu lesen.
Zudem sind die Eigenschaften eines Prozesses ohne weitere Einschränkungen nicht ausreichend, um eine hinreichend genaue Bestimmung vonehmen zu können.

Zitat von QuickAndDirty:

Das System richtig benutzen, d.h. die Datei die den Konflikt verursacht in den Ordner Eigene Dateien legen

Jeder Benutzer hat seine "Eigenen Dateien". Es ist auf einem Mehrbenutzersystem gar nicht so einfach _ein_ Verzeichnis zu finden, auf das _alle_ Benutzer zugreifen können.

Zitat von QuickAndDirty:

(InterProcessCommunication)IPC Clientstarten,nach IPC Server fragen, wenn der fehlt dann selbst IPC-Server starten.

Warum eine komplette Client-/Server-Implementation, wenn ein globales Objekt den gleichen Zweck erfüllt?

Hallo. Vielen Dank für eure Antworten. Ich werde in meinen Projekten ggf. auf die exklusiven Dateizugriffe achten oder, sofern erforderlich, nur in Benutzerverzeichnisse schreiben. Der Hinweis mit dem "Global\" bei den Mutex habe ich gesucht. Er wird vielleicht auch Verwendung finden. Den Code von SubData habe ich für die CodeLib vorgeschlagen.