possíveis, independentemente da cobertura das arestas de sincronização, tornou o experimento muito custoso (em termos de tempo de execução).
As arestas de sincronização não executáveis produzidas nos experimentos também foram analisadas. O intuito foi verificar se as arestas de sincronização que deixaram de ser cobertas eram realmente não executáveis ou se existia alguma que deveria ter sido coberta e não foi. Considerando que essa análise é manual (não é automatizada pela ValiPar) e também conside- rando a quantidade de arestas não executadas, optou-se por inicialmente escolher apenas alguns benchmarks e não o conjutno completo. A escolha dos benchmarks seguiu os seguintes critérios: (1) validar pelo menos um benchmark de cada paradigma (um de memória compartilhada, outro de passagem de mensagem e um com ambos os paradigmas); (2) os benchmarks devem ter padrões de comunicação diferentes; e (3) os benchmarks devem ser representativos, ou por serem problemas clássicos ou por terem uma quantidade de arestas não executáveis relativamente grande, porém, viáveis de serem validados manualmente.
Quatro benchmarks foram escolhidos: dois de passagem de mensagem, um de memória compartilhada e um com ambos os paradigmas (Parallel_GCD, TR_Same_Primitives, Readers_- Writers e Matrix_Both). A análise realizada revelou que todas as arestas de sincronização ditas não executáveis realmente o eram.
6.4 Experimentos com os Benchmarks com Defeitos In-
seridos
A Tabela11apresenta os resultados obtidos com os benchmarks com defeitos inseridos. A primeira coluna traz a identificação de cada benchmark. A segunda evidencia se o defeito foi revelado ou não pela ferramenta ValiPar. A terceira coluna destaca quantos casos de teste foram capazes de revelar o defeito dentre todos os casos pertencentes a cada benchmark. A quarta coluna indica se foi necessário, ou não, o auxílio da geração de variantes para revelar o defeito e, em caso afirmativo, a quantidade de variantes geradas até que o defeito fosse revelado. A quinta coluna mostra se foi possível, ou não, revelar o defeito observando a cobertura do critério all-sync-edges.
Para o benchmark Blocking_MP_PP_Fault o defeito (diferentes tamanhos de mensagens para sends e receives correspondentes) foi revelado, pois o módulo ValiExec exige que o buffer tenha um tamanho extra ao da mensagem a ser enviada, para que sejam inseridos dados de controle utilizados na geração dos arquivos de rastro. Ao executar este benchmark, a ferramenta reportou um erro do tipo message header inconsistent. Com o defeito apresentado no benchmark não foi necessário e nem possível o uso de variantes, já que se a execução livre falhar não haverá um rastro de execução completo para realizar a geração das variantes, e pelo mesmo motivo, o módulo ValiEval não reportou a cobertura do critério all-sync-edges.
Tabela 11 – Informações sobre a capacidade da ferramenta em revelar o defeito, quantidade de casos de teste que revelaram o defeito, necessidade, ou não, do auxílio da geração de variantes para se revelar o defeito, e em caso afirmativo, a quantidade de variantes geradas até revelar e, por fim, a possibilidade, ou não, de se revelar o defeito observando a cobertura das arestas de sincronização.
Benchmarks Defeito Revelado Casos de Teste Variantes/Quant. Sinc.
Blocking_MP_PP_Fault sim 0/0 não/0 não
Non_Blocking_MP_Fault sim 0/0 não/0 sim
Parallel_GCD_Fault_1 sim 3/3 não/0 não
Parallel_GCD_Fault_2 sim 1/3 não/0 sim
GCD_Two_Slaves_Fault sim 2/3 sim/17 não
All_to_All_Fault_1 sim 0/0 não/0 não
All_to_All_Fault_2 sim 0/0 não/0 não
Matrix_Fault sim 2/2 sim/26 não
Prod_Cons_Lock_Cond_Fault_1 não 0/4 não/0 não
Prod_Cons_Lock_Cond_Fault_2 sim 1/4 não/0 sim
SM_Fault_1 sim 0/0 não/0 sim
SM_Fault_2 sim 0/0 sim/3 sim
SM_Fault_3 sim 0/0 não/0 não
Considerando o benchmark Non_Blocking_MP_Fault a ferramenta conseguiu revelar o defeito inserido (retirada de comandos que influenciam na comunicação entre os processos) pela saída obtida na própria execução livre, não sendo necessário o suporte da geração de variantes para revelá-lo. A análise da cobertura das arestas de sincronização também possibilitou revelar o defeito, já que ao invés de apresentar a cobertura 4 de um total de 6 arestas, reportou a cobertura de apenas 2 das 6 arestas existentes.
Já para o benchmark Parallel_GCD_Fault_1 a ferramenta revelou o defeito (processo de destino incorreto num send) com a execução livre para os 3 casos de teste do benchmark, não sendo necessário e nem possível (devido a falta de um rastro de execução completo) gerar variantes para este caso. Como a execução livre não finalizou com sucesso para nenhum caso de teste, a ValiEval também não reportou a cobertura do critério all-sync-edges.
O defeito inserido no benchmark Parallel_GCD_Fault_2 (defeito no laço que antecede uma primitiva send) também foi revelado na execução livre. Apenas 1 dos 3 casos existentes revelou o defeito e não foi necessário o suporte da geração de variantes. Através da análise da cobertura do critério all-sync-edges é possível identificar o defeito, já que ao invés de cobrir 7 das 24 arestas existentes, apenas 6 foram cobertas.
Para o benchmark GCD_Two_Slaves_Fault o defeito (atribuição de forma incorreta usando variáveis) foi revelado por 2 dos 3 casos de teste existentes com o auxílio da geração de variantes, após 17 variantes geradas. Entretanto, a análise da cobertura do critério all-sync-edges não possibilitou revelar o defeito, já que a cobertura se manteve a mesma do benchmark sem defeito inserido (6 das 12 arestas de sincronização geradas pela ferramenta). Este fato indica que o defeito desse benchmark depende de uma sincronização específica entre os processos para que ele seja revelado.
6.4. Experimentos com os Benchmarks com Defeitos Inseridos 79
O defeito inserido no benchmark All_to_All_Fault_1 (inicialização incorreta de contado- res) foi revelado ainda na execução livre. Este benchmark utiliza barreiras (primitiva coletiva que não é considerada pelo algoritmo de geração de variantes) não sendo possível e nem neces- sário o suporte da geração de variantes. Devido, ainda, a uma limitação da própria ferramenta, observada com os experimentos com os benchmarks livres de defeios conhecidos, em que não são reportadas as arestas de sincronização para a primitiva barreira, o critério all-sync-edges não permite revelar o defeito.
Considerando o benchmark All_to_All_Fault_2 o defeito (outros sinais ausentes ou inexistentes) também foi revelado na execução livre, não sendo necessária e nem possível a geração de variantes. Devido à limitação descrita no parágrafo anterior o critério all-sync-edges não permite revelar o defeito.
Para o benchmark Matrix_Fault o defeito (operação não atômica assumida como atômica) foi revelado por 2 dos 2 casos de teste existentes com o auxílio da geração de variantes após 26 variantes geradas, entretanto, o critério não conseguiu revelar o defeito.
O benchmark Prod_Cons_Lock_Cond_Fault_1 foi o único que o defeito (outros sinais ausentes ou inexistentes) não foi revelado por nenhum caso de teste devido a uma limitação da própria ferramenta, que não considera locks explícitos e variáveis de condição, e já que esse defeito foi inserido nessa porção do código, o defeito não é revelado.
Para o benchmark Prod_Cons_Lock_Cond_Fault_2 o defeito (bloqueio de uma região crítica) é revelado por 1 dos 4 casos de teste existentes na própria execução livre, não sendo necessário o uso de variantes.
O defeito inserido no benchmark SM_Fault_1 (inicialização incorreta de contadores) é revelado pela saída obtida ainda na execução livre, não sendo necessário o auxílio da geração de variantes. Com a análise da cobertura das arestas de sincronização é possível revelar o defeito.
Considerando o benchmark SM_Fault_2 o defeito (operação não atômica assumida como atômica) foi revelado, entretanto, com o auxílio da geração de 3 variantes. A análise da cobertura das arestas de sincronização também revela o defeito.
Por fim, o defeito inserido no benchmark SM_Fault_3 (bloqueio incorreto) foi revelado ainda na execução livre pois o benchmark não finaliza com sucesso. Não foi necessário gerar variantes, e como a execução livre não finalizou com sucesso, o módulo ValiEval não reportou a cobertura dos critérios.
Assim, os experimentos realizados com os benchmarks com defeitos intencionalmente inseridos permitiram perceber que a ferramenta ValiPar é capaz de revelar vários tipos de defeitos, tanto de passagem de mensagem quanto de memória compartilhada. Foi possível verificar, também, que para alguns casos foi necessário o suporte da geração de variantes para forçar uma sincronização em específico que revelasse o defeito.
Por outro lado, os experimentos evidenciaram algumas limitações da ferramenta, como quando o rastro de execução está incompleto não sendo possível realizar a geração de variantes ou para defeitos presentes em benchmarks que usam primitivas de comunicação coletiva, também não suportadas pelo algoritmo de geração de variantes. Outra limitação é observada quando se tem primitivas como locks explícitos e variáveis de condição, não consideradas pelo módulo ValiInst.