nicht angemeldet
Hallo,
Ich halte die Idee mit der Datei nicht für so "famos" (obwohl ich praktisch dasselbe hier in einem Produkt implementiert habe, weil ich ein Semaphor auf einer shell-Ebene haben wollte und das am schnellsten ging ;-).
Wenn die Daten kostbar sind, dann ist eine Datei als Synchronisation nicht gut genug.
Das ist der Punkt die Daten sind sehr kostbar. Mit der besprochenen Lösung bin ich auf jeden Fall einen Schritt weiter.
Das Problem ist, daß es eine kritische Phase gibt, nämlich genau zwischen dem Prüfen der Sperr-Datei und dem Anlegen der Sperrdatei. Wenn das zwei Prozesse gleichzeitig versuchen, dann sind beide drin in der gefährlichen Zone.
Stimmt, auch das kann passieren. Habe ich auch schon in erwägung gezogen.
Der Trick muß darinbestehen, das Testen und das Setzen des Semaphors als unteilbare Operation durchzuführen. Auf alten Großrechnern gab es dafür bereits spezielle Maschinenbefehle "Test and Set", die genau so etwas mit einem Bit im Hauptspeicher tun konnten - selbst wenn durch einen Prozeßwechsel ein anderer Prozeß die CPU bekommt, kann er doch nicht diesen einen Befehl unterbrechen.
So gesehen ist flock() eine wesentlich zuverlässigere Methode.
Wenn Dir Deine Daten kostbar sind, dann solltest Du bei Synchronisation auf keinen Fall mit der zweitbesten Lösung zufrieden sein.
Durch die Diskussion in diesem Thread habe ich ja einiges zur Verwendung von flock() erfahren. Ich habe mir auch schon überlegt, ob es vielleicht eine Möglichkeit gibt (wenn überhaupt sinvoll) die Warteschleife und flock zu kombinieren. Es ist auch noch offen, ein Backup der Datei anlegen zu lassen. Diese Dinge zusammen müßten wohl ausreichen um die Daten so genau wie nur möglich aufzunehmen und zu speichern bzw. wieder zur Verfügung zu stellen.
Wie das nun genau aussehen könnte, weiß ich noch nicht ganz. Vielleicht hat aber noch jemand eine Idee.
Hansi