Na área de teste de programas concorrentes os benchmarks são desenvolvidos com o objetivo de determinar se os modelos conseguem representar os programas a serem testados, se os critérios conseguem revelar aqueles defeitos que se espera encontrar nos programas e se
as ferramentas de teste conseguem tratar, de modo eficiente, uma variada gama de códigos de entrada.
Um dos conjuntos de benchmarks mais conhecidos e utilizados na área de teste de progra- mas concorrentes são os disponibilizados pela IBM Haifa Research Lab (EYTANI; UR,2004). Trata-se de um conjunto de programas multi-threaded com defeitos intencionalmente inseridos, desenvolvidos por alunos da disciplina de teste de software, pelos próprios pesquisadores do laboratório de pesquisa da IBM, incluindo também programas de outras fontes como da NASA (CHEN; SERBANUTA; ROSU,2008). Os programas foram disponibilizados com o intuito de ajudar outros grupos de pesquisa a desenvolverem ferramentas e algoritmos de teste capazes de melhorar a qualidade dos programas concorrentes (EYTANI; TZOREF; UR,2008).
A própria IBM fez uso de tais benchmarks para testar sua ferramenta raceFinder (BEN- ASHER; FARCHI; EYTANI,2003), que utiliza novas heurísticas baseadas no monitoramento em tempo de execução, para aumentar a probabilidade de deteção de defeitos em programas concorrentes. Tal uso demonstrou alguns defeitos na ferramenta, revelados principalmente, pela forma não convencional de programação usada pelos estudantes, formas estas não consideradas no projeto da referida ferramenta (EYTANI; UR,2004).
Após quatro anos da disponibilização desse conjunto de benchmarks,Eytani, Tzoref e Ur(2008) fizeram um estudo para conhecer quais instituições utilizavam tal conjunto e para qual finalidade. O autor verificou que universidades no Canadá, na Espanha, nos Estados Unidos, na Índia e no Brasil estavam utilizando os benchmarks. Foi observado que para as pesquisas que tiveram o intuito de validar modelos, os autores preferiram utilizar os benchmarks menores, por serem mais fáceis de entender e de executar. O mesmo acontecendo quando o objetivo era testar ferramentas em fases iniciais de desenvolvimento. Os benchmarks maiores foram usados em ferramentas mais consolidadas. A maioria dos trabalhos focou na detecção de condições de disputa e violação de atomicidade.
O benchmark que simula a transferência de dinheiro entre diferentes contas bancárias, desenvolvido pela IBM, foi utilizado para testar a ferramenta jPredictor feita na Universidade de Illinois (CHEN; SERBANUTA; ROSU,2008). A jPredictor detecta defeitos de concorrência como condições de disputa e violação de atomicidade em programas Java.
Kidd et al. (2007) apresentam a implementação da ferramenta Empire, que realiza detecção estática de condições de disputa, que eles classificam como de alto nível. A avaliação da ferramenta foi feita com base em dez benchmarks da IBM, cujos defeitos foram listados como não atômicos. O uso dos benchmarks validou a abordagem empregada no projeto da ferramenta Empire que foi capaz de encontrar os defeitos corretamente em sete dos dez benchmarks.
Bradbury, Cordy e Dingel(2007) utilizaram quatro benchmarks da IBM com o objetivo de comparar duas ferramentas conhecidas de detecção de defeitos em programas concorrentes, a Java PathFinder (desenvolvida pela NASA) e a ConTest (desenvolvida pela IBM). Foram dois
4.2. Trabalhos Relacionados 45
os aspectos avaliados: a eficácia, que se refere à capacidade de cada ferramenta em detectar defeitos de concorrência, e aeficiência, que se refere à rapidez com que cada ferramenta é capaz de revelar esses defeitos. A execução dos benchmarks revelou a maior eficiência da ferramenta ConTest e o caráter complementar das duas ferramentas no quesito eficácia, já que as duas revelam os defeitos mas não usam a mesma forma para detectá-los.
Outro conjunto de benchmarks bastante utilizado é o deRungta e Mercer(2009). Trata-se de um pacote de benchmarks de programas concorrentes em várias linguagens de programação, como Java e C#, desenvolvidos para avaliar a capacidade de detecção de defeitos de várias ferramentas. Os autores reuniram um conjunto de benchmarks a partir de várias fontes (incluindo os da IBM citados anteriormente), e adicionaram novos programas desenvolvidos pelos próprios autores. Esses benchmarks foram utilizados para testar diferentes ferramentas, dentre elas a CHESS (MUSUVATHI et al.,2008) e a CalFuzzer (JOSHI et al.,2009).
Alguns benchmarks também são disponibilizados pelo grupo que desenvolveu a Inspect (YANG,2013). A Inspect é outra ferramenta para teste de programas concorrentes escritos em C, tendo como objetivo detectar defeitos tais como condições de disputa e deadlocks. Os programas desenvolvidos para testar a ferramenta estão disponíveis em seu site e podem ser utilizados por outros grupos de pesquisa.
Helgrind (VALGRIND-DEVELOPERS,2013) é uma ferramenta para detectar defeitos de sincronização em programas escritos em C, C++ e Fortran que usam as primitivas do padrão POSIX para threads. Esta ferramenta pode detectar três classes de defeitos: má utilização da API POSIX pthreads, deadlocks e condições de disputa. No site da ferramenta são disponibilizados alguns códigos de exemplo que podem ser usados como benchmarks para o teste de outras ferramentas.
Os benchmarks citados anteriormente são implementados em um único paradigma, ou seja, ou exclusivamente de memória compartilhada ou apenas passagem de mensagem. A nova ferramenta ValiPar, que foi objeto de estudos neste trabalho de mestrado, permite o teste de programas que faz uso de ambos os paradigmas de programação, inclusive em um mesmo programa. Até onde pode-se levantar, não encontramos benchmarks para o teste de programas concorrentes que usem simultâneamente ambos os paradigmas de comunicação e sincronização e que avaliem o teste de programas concorrentes de maneira abrangente, considerando modelos, critérios e ferramentas.
Notou-se, também, que os benchmarks, até mesmo os mais usados como os da IBM (EYTANI; TZOREF; UR,2008) e Rungta (RUNGTA; MERCER,2009), já não atendem todas as expectativas devido ao caráter evolutivo de algumas linguagens. Java, por exemplo, sofreu muitos incrementos de funcionalidades que mudaram a forma de se construir programas concorrentes, principalmente a partir da versão 5.0. A nova ferramenta ValiPar foi implementada para testar programas que usam novas primitivas para programação concorrente em Java, sendo necessário que os benchmarks façam uso dessas primitivas. Além disso, o aumento da quantidade das
interações entre os processos/threads e a cobertura parcial dos códigos, através de distintos dados de teste, são outros fatores relevantes que precisam ser considerados e que não são contemplados nos benchmarks encontrados na literatura. Todos esses aspectos reforçam a viabilidade e a importância deste trabalho de mestrado para a área de teste de software de programas concorrentes.