Como as condições de corrida afetam as leituras e gravações (que acontecem ao mesmo tempo)

Question

Digamos que eu abro um arquivo a para leitura. E se uma aplicação, vamos chamá-lo aWriter escreve para este arquivo em intervalos aleatórios. Existe alguma possibilidade de eu receber conteúdo de arquivo inadequado se eu tentar abrir a para uma leitura e ao mesmo tempo aWriter está escrevendo uma nova linha. O que acontece com o arquivo e o que acontece com o que recebo da minha leitura.

Outro cenário. Digamos que eu tenha um arquivo b que contém 100 linhas de texto. Eu também tenho um aplicativo bWriter que grava em b em tempos aleatórios. Eu quero remover as primeiras 80 linhas de arquivo b . Vamos supor que bWriter queira escrever para b enquanto eu o abrir, ele ainda será capaz de escrever? Vai desistir e perder é escrever?

Eu pergunto porque estou escrevendo um script Perl que se conecta ao Syslog. Eu apontei o Syslog para escrever todos os logs em um arquivo e meu script precisa (a cada 5 minutos) ler o conteúdo do arquivo, fazer algumas outras coisas, então remover todas as linhas daquele arquivo e gravar as linhas antigas em um arquivo. . Estou usando o arquivo como um passo intermediário entre o meu script e o local de descanso final para os registros.

Alguém pode me dar uma ideia de como exatamente isso funciona?

    

Answer 1

Dois processos podem ter o mesmo filehandle aberto para gravação. Assim como com qualquer coisa, a última execução vence.

Quando um processo abre um filehandle, algum outro processo grava 80 linhas nele, o buffer de memória do primeiro processo não terá essas 80 linhas. Se ele gravar o buffer no filehandle, o conteúdo do arquivo será apenas o que estava no segundo buffer de memória.

Agora, muitos desses programas detectam que o conteúdo original do arquivo mudou desde a última vez em que foi aberto. Alguns se recusarão a escrever, alguns solicitarão que você recarregue o buffer. Alguns podem fazer outra coisa. Cabe a cada programa para se certificar de que faz a coisa certa. O kernel / sistema de arquivos não se importa, e para todos, ele sabe que o buffer de memória que falta 80 linhas é a cópia correta .

Agora, se for algo significativamente mais importante, digamos, um banco de dados, em vez de apenas um arquivo de texto ou documento no diretório inicial, é muito mais provável que o bloqueio de arquivos seja usado (o que também não significa que vim ou gedit não usam bloqueios). Um banco de dados provavelmente terá seu próprio mecanismo de bloqueio interno.

A filosofia geral em plataformas de estilo UNIX é ser cooperativa em relação às gravações de filehandle. O bloqueio não é um mecanismo de controle de segurança (é para isso que as permissões / ACLs são), é um mecanismo de integridade de dados. Dois programas que desejam gravar dados geralmente querem garantir que os dados sejam gravados corretamente, portanto, é benéfico respeitar os bloqueios uns dos outros. O kernel / sistema de arquivos avisará sobre bloqueios, mas ainda assim permitirá que cada processo faça o que achar melhor. No entanto, o Linux suporta a aplicação de bloqueio obrigatório como uma opção de montagem (isso também pode exigir suporte ao sistema de arquivos, mas não tenho certeza disso).

Você pode ler mais informações sobre bloqueios no artigo sobre bloqueio de arquivos da Wikipedia .