Moin Moin!
BTW, um auf die Frage vorhin zurückzukommen... ist Prüfen auf Vorhandensein einer Datei mit
-e
(if (-e "datei")
) zuverlässig?
Nur insoweit, als dass das Ergebnis Dir sagt, dass zum Zeitpunkt des stat()-Syscalls eine Datei "datei" existierte. Was in den folgenden CPU-Zyklen passiert (z.B. ein zwischenzeitlicher Taskwechsel zu "rm -f datei"), garantiert dir niemand.
Der große Haken an Locking ist, dass es ATOMAR sein muß. Alles andere funktioniert nur zufällig so lange, bis wirklich mal zwei oder mehr Instanzen parallel laufen. Richtig interessant wird Locking, wenn mehr als ein CPU-Kern im Spiel ist, egal ob simuliert in Hyperthreading, oder echt (Mehrkern-CPUs, Mehr-CPU-Systeme). Wenn man Locking richtig testen will, braucht man ein System mit mehr als einem CPU-Kern, idealerweise mit zwei oder mehr unabhängigen CPUs.
Jedes ernst zu nehmende RDBMS hat diese Probleme gelöst. PostgreSQL und Oracle haben interne Locking-Mechanismen, die auch auf Mehr-CPU-Systemen absolut sicher funktionieren. MS SQL Server ist beim Locking gelegentlich "etwas" vermurkst und rennt gerne mal in einen Deadlock, der wird aber erkannt und gemeldet. Nicht schön, aber handhabbar. Die SQLite-Doku behauptet auch, dass SQLite mit parallelen Prozessen auf dem selben File umgehen kann. MySQL ist wohl meistens auch unproblematisch, je nach Storage. Genaue Erfahrungen mit SQLite und MySQL fehlen mir, deswegen die etwas wagen Formulierungen.
Alexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".