Ist glibcs ​​Implementierung von fprintf () threadsicher?

7

Ist fprintf threadsicher? Das glibc-Handbuch scheint es zu sagen, aber meine Anwendung, welche schreibt in eine Datei mit einem Aufruf von fprintf () scheint partielle Schreibvorgänge von verschiedenen Prozessen zu mischen.

edit: Zur Klarstellung ist das fragliche Programm ein lighttpd Plugin, und der Server läuft mit mehreren Worker-Threads.

Beim Betrachten der Datei sind einige der Schreibvorgänge vermischt.

edit 2: Es scheint, dass das Problem, das ich sehe, darauf zurückzuführen sein könnte, dass die "Worker Threads" von lighttpd eigentlich separate Prozesse sind: Ссылка

  

Probleme

     

Durch Ausführen von 2 oder mehr Prozessen auf dem   selbe Steckdose wirst du besser haben   Nebenläufigkeit, wird aber ein paar haben   Nachteile, die Sie beachten müssen   von:

     
  • mod_accesslog erstellt möglicherweise fehlerhafte Zugriffsprotokolle, da dieselbe Datei zweimal geöffnet und NICHT synchronisiert wird.
  •   
  • mod_status hat n separate Zähler, jeweils einen Satz   Prozess.
  •   
  • mod_rrdtool schlägt fehl, da es zweimal den gleichen Zeitstempel erhält.
  •   
  • mod_uploadprogress zeigt den korrekten Status nicht an.
  •   
    
John Carter 27.02.2009, 13:56
quelle

3 Antworten

14

Sie verwechseln zwei Konzepte - Schreiben aus mehreren Threads und Schreiben aus mehreren Prozessen.

Innerhalb eines Prozesses kann sichergestellt werden, dass ein Aufruf von fprintf abgeschlossen ist, bevor dem nächsten Zugriff auf den Ausgabepuffer gewährt wird. Sobald Ihre App diese Ausgabe jedoch in eine Datei pumpt, sind Sie dem Betriebssystem ausgeliefert. Ohne irgendeine Art von OS-basiertem Sperrmechanismus können Sie nicht sicherstellen, dass eine völlig andere Anwendung nicht in Ihre Protokolldatei schreibt.

    
PaulJWilliams 27.02.2009, 14:01
quelle
7

Klingt für mich so, als müssten Sie auf Dateisperre nachlesen. Das Problem, das Sie haben, ist, dass mehrere Prozesse (d. H. Nicht Threads) gleichzeitig in dieselbe Datei schreiben und es gibt keine zuverlässige Möglichkeit, sicherzustellen, dass die Schreibvorgänge atomar sind. Dies kann dazu führen, dass Dateien die Schreibvorgänge, die gemischte Ausgabe und das insgesamt nicht deterministische Verhalten gegenseitig überschreiben.

Das hat nichts mit Thread-Sicherheit zu tun, da dies nur in Single-Process Multithreading-Programmen relevant ist.

    
dsm 27.02.2009 14:09
quelle
2

Der aktuelle C ++ - Standard sagt nichts über Parallelität aus, ebenso wenig wie der C-Standard von 1990. (Ich habe den C-Standard von 1999 nicht gelesen, kann also nichts dazu sagen; der kommende C ++ 0x-Standard sagt Dinge aus, aber ich weiß nicht genau, was sich daraus ergibt.)

Dies bedeutet, dass fprintf () selbst wahrscheinlich weder Thread-sicher noch anderweitig ist und dass es von der Implementierung abhängen würde. Ich habe genau gelesen, was die glibc-Dokumentation dazu sagt, und vergleiche es genau mit dem, was du tust.

    
David Thornley 27.02.2009 15:16
quelle