Re: Wie oft wird Programm aufgerufen?

Dirk Clemens <usenet-trash@xxxxxxxxxx> writes:

Hauke Laging wrote:
Heike C. Zimmerer schrieb am Dienstag 27 November 2007 00:50:

Ja, dabei Zähler-Lock nicht vergessen. Der wiederum flüstert ganz
gerne leise die Warnung "race condition". Nicht überhören, sonst
schreit später ein Anwender umso lauter. So'n einfacher Zähler
kann kompliziert werden.

Wieso? write() funktioniert doch blockweise atomar:

date ... >> /mein/zähler

Man muss halt nur die Ausgabe von date unter 513 Byte halten. Eine
meines Erachtens durchaus umsetzbare Anforderung.

Das war auch mein erster Gedanke, so mache ich es, wenn es auf
die genaue Anzahl nicht ankommt. Und empirisch scheint alles
glatt zu laufen.

Aber ich habe so meine Zweifel und hatte daher diese nahe liegende
Lösung *nicht* gepostet.

Ist denn aber auch wirklich atomar?

Denn zwischen "Datei am Ende öffnen" (und damit den file pointer
festlegen) und dem "Schreiben der Zeile" könnte ein Taskwechsel
stattfinden.

Das kommt darauf an:

$ uname -sr
Linux 2.6.18-5-686

Aus bash(1):

Appending Redirected Output
Redirection of output in this fashion causes the file whose name
results from the expansion of word to be opened for appending on
file descriptor n, or the standard output (file descriptor 1) if n
is not specified. If the file does not exist it is created.

Aus dem Single Unix Specification:

2.7.3 Appending Redirected Output

Appended output redirection shall cause the file whose name results
from the expansion of word to be opened for output on the designated
file descriptor. The file is opened as if the open() function as
defined in the System Interfaces volume of IEEE Std 1003.1-2001 was
called with the O_APPEND flag. If the file does not exist, it shall be
created.

Aus open(2):

O_APPEND
The file is opened in append mode. Before each write(), the
file offset is positioned at the end of the file, as if
with lseek(). O_APPEND may lead to corrupted files on NFS
file systems if more than one process appends data to a
file at once. This is because NFS does not support
appending to a file, so the client kernel has to simulate
it, which can’t be done without a race condition.

Aus dem Single Unix Specification zu open():

O_APPEND
If set, the file offset shall be set to the end of the file prior
to each write.

Dass extra NFS erwähnt wird, legt nahe, dass es in den Fällen mit NFS
einen Unterschied zu denen ohne NFS gibt. Wenn die Fälle ohne NFS
ebenfalls ein race condition hätten, wäre das Erwähnen von NFS unnötig.

Before each write(), the file offset is positioned at the end of the
file, as if with lseek().

[...]

This is because NFS does not support appending to a file, so the
client kernel has to simulate it, which can’t be done without a race
condition.

Daraus schließe ich, dass im Fall ohne NFS gilt: The kernel, which is as
well client and server, doesn't have to simulate appending to a file: It
/can/ do it: Whenever it comes to write to the file, the file pointer
is positioned to the end of the file, after which the data are written to
it; and this operation is atomic.

Falsch? Ich meine, nicht.
--
Wer mir E-Mail schreiben will, stelle | When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen | precede my e-mail address with
Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <xxx@xxxxxxxxxxx>, (Helmut Waitzmann) xxx@xxxxxxxxxxx
.