É a implementação da glibc de fprintf () thread-safe?
-
09-09-2019 - |
Pergunta
É fprintf thread-safe? O glibc o manual parece dizer que é , mas a minha candidatura, que grava em um arquivo usando uma única chamada para fprintf () parece estar misturando as gravações parciais de processos diferentes.
Edit: Para esclarecer, o programa em questão é um lighttpd plugin, eo servidor está sendo executado com threads múltiplos trabalhadores.
Olhando para o arquivo, algumas das gravações são misturadas.
Editar 2: Parece que o problema que eu estou vendo pode ser devido a "threads de trabalho" do lighttpd realmente sendo processos separados: http: //redmine.lighttpd. líquidas / wiki / lighttpd / Docs: multiprocessador
Problema
Ao executar 2 ou mais processos no mesmo soquete que você terá uma melhor simultaneidade, mas terá alguns inconvenientes que você tem que estar ciente de:
- mod_accesslog pode criar logs de acesso quebrado, como o mesmo arquivo é aberto duas vezes e não está sincronizado.
- mod_status terão n contadores separados, um conjunto para cada processo.
- mod_rrdtool irá falhar como ele recebe a mesma hora duas vezes.
- mod_uploadprogress não vai mostrar status correto.
Solução
Você está confundindo dois conceitos -. Escrita de vários segmentos e escrever a partir de vários processos
Dentro de um processo de sua possível para garantir que uma invocação de fprintf é concluída antes do próximo é permitido o acesso ao buffer de saída, mas uma vez que seu aplicativo bombas que a saída para um arquivo que você está à mercê do sistema operacional. Sem algum tipo de sistema operacional baseado mecanismo de bloqueio que você não pode garantir que uma gravação completamente diferente does not aplicativo para o seu arquivo de log.
Outras dicas
Parece-me que você precisa ler sobre bloqueio de arquivos . O problema que você tem é que vários processos (ou seja, não threads) está escrevendo para o mesmo arquivo ao mesmo tempo e não há nenhuma maneira confiável para segurar as gravações será atômica. Isso pode resultar em arquivos sobrescrevendo escreve um do outro, a produção mista e comportamento totalmente não-determinista.
Isto não tem nada a ver com thread-safe, como isso é relevante apenas em programas de multithreading de processo único.
O padrão atual C ++ diz nada de útil sobre a concorrência, nem o padrão de 1990, C. (Eu não li o padrão 1999 C, por isso não posso comentar sobre isso;. A próxima C ++ 0x padrão diz coisas, mas eu não sei exatamente o improviso)
Isto significa que fprintf () é provável si só, não thread-safe, nem de outra forma, e que iria depender da implementação. Eu tinha lido exatamente o que a documentação glibc diz sobre isso, e compará-lo com exatamente o que você está fazendo.