Baixe Resenha crítica artigo e outras Resumos em PDF para Sistemas Operacionais, somente na Docsity!
Instituto Federal Sul-Rio-Grandense - Campus Passo Fundo Disciplina: Sistemas Operacionais II Professor: Roberto Wiest Aluno: Mateus de Oliveira Gomes
Resenha crítica do artigo “Detecting Bugs of Concurrent Programs With Program Invariants”
Introdução
O artigo “Detecting Bugs of Concurrent Programs With Program Invariants”, feito por Rong Wang e Zuohua Ding (Zhejiang University of Science and Technology), Ning Gui(Central South University, Changsha, China), e Yang Liu(Nanyang Technological University), trás um estudo aprofundado a respeito da detecção de falhas em programas concorrentes com invariantes. Ele é dividido em oito seções, sendo a primeira de Introdução, seguindo de uma visão geral das técnicas abordadas, descrição das falhas e programas invariantes, a forma de detecção de falhas, resultados experimentais, explicação da validação de tratamento, discussão de trabalhos relacionados , conclusão e por fim, após as oito seções, as referências.
Resumo
Seção II
Primeiramente, é apresentada uma visão geral da abordagem, onde é explicado passo a passo dos testes feitos com componentes de programas concorrentes. Para o experimento, os programas foram executados em duas Threads, que acessam uma mesma variável X. Onde a thread 1 é composta por uma função que escreve no X, e a thread 2, que é composta por quatro funções, e a primeira delas lê o valor de X. Foi usada uma técnica de detecção de falhas proposta por Sangmin Park, Richard W. Vuduc, Mary Jean Harrold, no artigo “ Falcon: Falha Localização em programas concorrentes ”, e a partir dela foi identificado que a thread 1 modifica a variável compartilhada X antes da Thread 2 lê-la. mas apesar disso, foi concluído que ela não é a ideal para os testes efetivos, pois esse padrão obtido através da fórmula proposta com os dados do gráfo da chamada da função não poderia dizer quais as partes da thread 1 e thread 2 interagem incorretamente. Além disso, se os erros de simultaneidade se relacionam com múltiplas variáveis, a técnica pode não funcionar.
Seção III
Após a apresentação do resultado dos testes, e avaliação da técnica usada, é feita a descrição dos tipos de falha a serem detectados e a conceituação de invariantes e a forma de obtenção deles.
o primeiro ponto a ser colocado é a divergência entre as falhas de correncencia introduzidos pelos autores do artigo resenhado e pelos autores do artigo usado como base para o primeiro teste. colocado essa ressalva, é feita a descrição das falhas de concorrência a serem detectadas. E são elas, violação de ordem , violação de atomicidade, problema de impasse e má composição. Seguindo a apresentação das falhas, vem a descrição de invariantes, que são propriedades usadas em documentações e especificações formais que faz relação direta com o resultado da execução. Podem ser compreendidos com validações que inferem no andamento da execução, como por exemplo duas variáveis que recebem dois valores, e a partir deles serão feitas verificações a depender de qual condição se adequa, será executado mais um ou vários invariantes. Várias ferramentas podem ser usadas para identificar esses invariantes e a partir de análise levantar dados para detectar a possível causa de um falha. algumas ferramentas usadas por trabalhos relacionados são descritas, como DIDUCE, desenvolvida por Hangal e MS Lam em “Tracking down software bugs using automatic anomaly detection”, IODINE também desenvolvida por Hangal juntamente com N. Chandra, S. Narayanan, e S. Chakravorty em “IODINE: A tool to automatically infer dynamic invariants for hardware designs” para extrair automaticamente invariantes dinâmicos, como pares de solicitação-reconhecimento e exclusão mútua entre os sinais para projetos de hardware, e a daikon desenvolvida por M. D. Ernst, J. Cockrell, W. G. Griswold, and D. Notkin em “Dynamically discovering likely program invariants to support program evolution” que foi usado para detectar os invariantes no artigo resenhado. E após apresentar essas ferramentas, é apresentado o funcionamento da daikon, por ser ela a utilizada. Resumidamente, as fases necessárias para a detecção feito pela daikon é, geração de um conjunto de testes, Habilitação de invariantes, execução do programa com os casos de teste e obtenção dos dados e obtenção dos invariantes.
Seção IV
Na sessão IV é descrito aprofundadamente com detectar as falhas com invariantes na forma que os autores propuseram. Começando pelos invariantes, são colocados em tabelas para fazer uma melhor distinção e encontrar um padrão, e em seguida busca um relação linear em em meio ao padrão identificado. dito isso, é posto em questão uma parte muito importante, a de geração e invariantes falhas, que justifica ainda mais o processamento feito para organizá-los, pois são através deles que serão encontrados os chamados “falsos
O software Conta(Fonte: repositório de infra-estrutura (SIR)) apresentou problema de impasse. O software Sistema de elevador(fonte: https://github.com/dylangsjackson/Elevator ) não apresentou nenhuma falha.
Seção VII
na seção 7, é feita uma descrição para cada trabalho que influenciou e foi utilizado para qualquer estágio do artigo resenhado, alguns destes trabalhos, inclusive, foram citados acima.
Seção VIII
Na última seção, é posta a conclusão do artigo, onde são destacadas as vantagens do método utilizado para detecção de falhas com invariantes, sendo elas a localização das falhas, a verificação de muitos tipos de invariantes ao invés de máscara de bits, detecção de vários tipos de falhas e a ausência da necessidade de oráculo para o monitoramento dos pontos do programa.
Conclusão
O artigo, que tem como objetivo apresentar uma melhor maneira de detectar falhas em programas concorrentes usando invariantes, cumpriu com o seu propósito, abordando aprofundadamente os passos para chegar ao resultado obtido, sendo bem específico e detalhado, e pôde até mesmo mostrar mais eficácia em relação aos trabalhos anteriores que abordaram o mesmo tema.
