Der Grund koennte auch sein, dass es mehrere Webserver gibt, die sich die Daten ueber NFS teilen.

[quote=jan,17.04.2006, 20:49]<a href="http://www.awprofessional.com/articles/article.asp..." target="_blank">http://www.awprofessional.com/article....=2&rl=1</a>

beschreibt, wie du das entspannter löst - denn auch mit flock kann's zum datenverlust kommen - immerhin ist zwischen dem open und dem flock sonst immer noch eine race-condition.[/quote]
wieso kann es zu datenverlust kommen? ich mache ein open(), dann ein
flock(). erst, wenn die datei freigegeben ist, wird mein eigener lock
aktiv. und dann bearbeite ich die datei. wenn ich sie nicht gerade mit ">"
geöffnet habe, wo sollen da daten verloren gehen? habe ich jetzt irgendwas verpasst?

[quote=pq,18.04.2006, 00:32]wieso kann es zu datenverlust kommen? ich mache ein open(), dann ein flock(). erst, wenn die datei freigegeben ist, wird mein eigener lock aktiv. und dann bearbeite ich die datei. wenn ich sie nicht gerade mit ">" geöffnet habe, wo sollen da daten verloren gehen?[/quote]
Genau das macht der OP aber in seinem Code, siehe oben, 3. Beitrag. Kein Wunder, dass es schief geht.

Diesen Artikel aus "Writing CGI Applications with Perl" finde ich nebenbei ziemlich schwach. Der Autor kritisiert einen Code, der flock() nutzt und Race Conditions zeigt. Statt diese Race Conditions zu beseitigen (was problemlos ginge, siehe "perldoc -q 'get locking'", da wird das gleiche Problem gelöst), schlägt er Lockdateien vor, ohne auf deren Nachteile hinzuweisen (Crash der Applikation oder Server-Neustart können z.B. zu verwaisten Lockdateien führen) und Abhilfe zu zeigen (Abräumen veralteter Lockdateien), und zeigt dann Beispiel-Code, der beim flock() der Lockdatei selber wieder eine Race Condition hat (hier aber ohne große Auswirkungen, da der Inhalt der Datei nie ausgewertet wird)!

@pq usw.

Dieses Race-condition Problem hatte ich auch mal. (bei einem counter) und plötzlich war er leer, trotz flock.

Stellt euch nur vor ein anderer Prozess (Perlskript z. B. counter) greifft gerade auf die Datei zu in der Zwischenzeit.
Das Passiert, wenn's dumm kommt gerade dann, wenn flock noch nicht abgearbeitet wurde.

Zwischen "open" und dem Befehl "flock" vergeht viel Zeit.
Die Datei wird zuerst geöffnet und erst danach geflockt.
In der Zeit kann vieles passieren.

Eigentlich müsste man die datei zuerst flocken, dann öffnen. aber das geht ja so nicht..


--------
Am besten bei solchen Sachen einfach sysopen nehmen, dann sind die Probleme hinfällig.

[quote=master,18.04.2006, 09:22]@pq usw.

Dieses Race-condition Problem hatte ich auch mal. (bei einem counter) und plötzlich war er leer, trotz flock.

Stellt euch nur vor ein anderer Prozess (Perlskript z. B. counter) greifft gerade auf die Datei zu in der Zwischenzeit.
Das Passiert, wenn's dumm kommt gerade dann, wenn flock noch nicht abgearbeitet wurde.

Zwischen "open" und dem Befehl "flock" vergeht viel Zeit.
Die Datei wird zuerst geöffnet und erst danach geflockt.
In der Zeit kann vieles passieren.

Eigentlich müsste man die datei zuerst flocken, dann öffnen. aber das geht ja so nicht..


--------
Am besten bei solchen Sachen einfach sysopen nehmen, dann sind die Probleme hinfällig.[/quote]
das ist absoluter quatsch. warum, hat dubu erklärt.
erst nach dem flock bearbeitest du die datei. was zwischen dem open und
flock passiert, kann dir schnuppe sein.
es gibt bei einem richtig benutzten flock keine race-condition.
können wir uns mal darauf einigen?
ansonsten hätte ich gerne eine demonstration, dass es schief geht.
einfach ein sleep zwischen dem open und dem flock einbauen und das
skript zweimal starten. dann kannst du ja das ergebnis hier vorstellen.\n\n

<!--EDIT|pq|1145355838-->

[quote=Dubu,18.04.2006, 02:09][quote=pq,18.04.2006, 00:32]wieso kann es zu datenverlust kommen? ich mache ein open(), dann ein flock(). erst, wenn die datei freigegeben ist, wird mein eigener lock aktiv. und dann bearbeite ich die datei. wenn ich sie nicht gerade mit ">" geöffnet habe, wo sollen da daten verloren gehen?[/quote]
Genau das macht der OP aber in seinem Code, siehe oben, 3. Beitrag. Kein Wunder, dass es schief geht.
[/quote]
ich bezog mich auf den artikel und auf jans aussage
"denn auch mit flock kann's zum datenverlust kommen - immerhin ist
zwischen dem open und dem flock sonst immer noch eine race-condition."
was der OP macht, steht nochmal auf einem anderen blatt.

[quote=master,18.04.2006, 09:22]Zwischen "open" und dem Befehl "flock" vergeht viel Zeit.[/quote]
ähm, wie kommst du darauf? in der regel vergeht da so gut wie gar keine
zeit. du meintest wohl, "es kann viel zeit vergehen. das stimmt.
na und?

Quote

Die Datei wird zuerst geöffnet und erst danach geflockt.
In der Zeit kann vieles passieren.

was denn z.B.?

@pq

Ganz einfach...
Bin mir nicht ganz sicher aber denke die Datei wird gelöscht und dann neu erzeugt. Bei sysopen ist das jedenfalls nicht so.

Prozess 1:
Hat gerade den Befehl open() ausgeführt.

Prozess 2:
Öffnet nun im dümmsten moment die (ungeflockte-)Datei ebenfalls, weil der Prozess 1 noch nicht zum befehl "flock" kam.

Nun kommt Prozess 1 zum Befehl "flock" und sichert die datei für sich.

Das Problem ist das Multitasking.
Wenn du nur 1 Prozess startest, passiert nichts.
Schreibst du aber z.B. einen counter oder irgendwas anderes bei dem Mehrere Prozesse auf die selbe Datei zugreiffen wirds gefährlich, besonders wenn 2 (fast)gleichzeitig darauf zugreiffen....

Durch das multitasking bekommt nun also Prozess 1 und 2 die CPU-Zeit aufgeteilt.
Nach einigen millisekunden bekommt dann Prozess 2 die CPU, dann Prozess 3 usw. a schluss wieder Prozess 1.

Der Anwender merkt das nicht, weil es unglaublich schnell abläuft.

Du kannst also der CPU nicht sagen, mach jetzt nur mein Skript und blockiere alles andere... (war auf dem Amiga mal möglich so das Multitasking zu überlisten und die CPU an sein Programm zu binden) aber heutzutage geht das wegen des total erzwungenen Multitaskings nicht mehr bzw.

Somit kannst du dich nicht darauf verlassen, das nix passiert zwischen open und flock.

Problematisch ist das vorallem für Dateisystemsachen und teils SQL.

und bei dateien rate ich in demfall zu opensys, weil das die Datei mit 100% sicherheit nicht woanders neu erzeugt...
Zudem ist sysopen auch einiges schneller...

Hm, das Problem hast du doch nur, wenn eine Anwendung ohne flock() auf die Datei zugreift oder?
Wenn ich das aus der Doku zu flock richtig lese, muesste man das Ergebnis von flock in ner Schleife auswerten. Sprich, ich warte solange, bis mir das flock ein TRUE zurueckgibt und damit anzeigt, dass er erfolgreich das Lock erhalten hat.
Solange von flock ein FALSE kommt, muss die Anwendung weiter warten.
Oder sehe ich das nun falsch?

[quote=master,18.04.2006, 13:33]Bin mir nicht ganz sicher aber denke die Datei wird gelöscht und dann neu erzeugt. Bei sysopen ist das jedenfalls nicht so.
[/quote]
master, bitte...
mit flock() kannst du ohne race-condition daten verarbeiten. und
wenn zwei prozesse noch so schnell dasselbe tun. genau dafür ist
flock doch da, denn es ist eine atomare operation.
ich warte immer noch auf konkreten code und eine demonstration.
bzw.: wo soll bei folgendem code eine race-condition sein?