Est-ce que la mise en œuvre de la glibc de fprintf () thread-safe?

Question

est thread-safe fprintf? Le manuel glibc semble dire qu'il est , mais ma demande, qui écrit dans un fichier en utilisant seul appel à fprintf () semble entremêlement écriture partielle des différents processus.

edit: Pour clarifier, le programme en question est un lighttpd plugin, et le serveur est en cours d'exécution avec plusieurs threads de travail.

En regardant le fichier, quelques-unes des écritures sont entremêlées.

modifier 2: Il semble que le problème que je vois peut-être dû aux « threads de travail » de lighttpd étant en fait des processus distincts: href="http://redmine.lighttpd.net/wiki/lighttpd/Docs:MultiProcessor" rel="nofollow noreferrer"> http: //redmine.lighttpd. net / wiki / lighttpd / Docs: MultiProcessor

  

Problèmes

     

En exécutant 2 ou plusieurs processus sur la   même socket, vous aurez une meilleure   concurrency, mais aura quelques   inconvénients que vous devez être au courant   de:

     

  
• mod_accesslog peut créer des journaux d'accès brisés, comme le même fichier est ouvert deux fois et n'est pas synchronisé.
  
• mod_status aura n compteurs séparés, un pour chaque   processus.
  
• mod_rrdtool échouera car il reçoit deux fois le même horodatage.
  
• mod_uploadprogress ne sera pas affiché état correct.
  

Answer 1

Vous confondez deux concepts -. Écriture de plusieurs threads et de l'écriture de plusieurs processus

Dans un processus il est possible de faire en sorte que l'une invocation de fprintf est terminée avant la prochaine est autorisé à accéder à la mémoire tampon de sortie, mais une fois votre application pompes que la sortie vers un fichier que vous êtes à la merci de l'OS. Sans une sorte de mécanisme de verrouillage basé OS vous ne pouvez pas vous assurer que l'application ne marche pas un tout autre écrire à votre fichier journal.

Answer 2

me semble que vous devez lire sur le verrouillage de fichier . Le problème que vous avez est que plusieurs processus (à savoir non threads) sont en train d'écrire dans le même fichier en même temps et il n'y a aucun moyen fiable pour assurer les écritures sera atomique. Cela peut entraîner des fichiers de chaque écriture d'écraser les autres, la production mixte, et le comportement tout à fait non-déterministe.

Cela n'a rien à voir avec la sécurité de cette discussion, car cela ne concerne que dans les programmes de multithreading un seul processus.

Answer 3

La norme actuelle C ++ ne dit rien utile sur la concurrence, ni ne la 1990 C standard. (Je l'ai pas lu 1999 standard C, ne peut donc pas commenter,. La prochaine norme C ++ 0x ne dit les choses, mais je ne sais pas exactement ce que Morisque)

Cela signifie que fprintf () lui-même est susceptible ni thread-safe, ni autrement, et que cela dépendrait de la mise en œuvre. Je lis exactement ce que la documentation glibc dit à ce sujet, et le comparer à exactement ce que vous faites.