Aplicação de Teste Estrutural para Programas Multithreads Baseados em

Semáforos∗

Felipe Santos Sarmanho Paulo Sérgio Lopes de Souza Simone do Rocio Senger de Souza
Adenilso da Silva Simão

Instituto de Ciências Matemáticas e de Computação – Universidade de São Paulo

Cx. Postal 668 - 13560-970 - São Carlos - SP - Brasil
{sarmanho, pssouza, srocio, adenilso}@icmc.usp.br

Resumo O teste de programas tem por objetivo principal executar

Programas concorrentes são importantes para reduzir o
tempo de resposta de diversos tipos de aplicações. Porém, o
teste desses programas é muito difícil devido a características
como comunicação, sincronização e não-determinismo. Este
trabalho apresenta a aplicação do modelo de teste P CF G
(Parallel Control Flow Graph), proposto para programas
concorrentes com passagem de mensagem, em programas
concorrentes com memória compartilhada. O principal obs-
táculo é a representação da comunicação, que em passagem
de mensagem ocorre de forma explícita e em memória com-
partilhada ocorre implicitamente. É mostrada a viabilidade
da representação de programas concorrentes com memória
compartilhada através do P CF G. Porém destaca-se a ne-
cessidade de extensões para evidenciar informações relati-
vas à comunicação. Um protótipo da ferramenta, denomi-
nada ValiPhtread, para automatizar a aplicação do modelo
de teste P CF G em programas multithreads está em desen-
volvimento.
1 Introdução
Um programa concorrente é composto por um conjunto de
tarefas (threads ou processos) que interagem entre si para re-
alização de um trabalho maior. Um programa multithread é
um tipo especial de programa concorrente composto por dife-
rentes linhas de execução chamadas threads, as quais compar-
tilham um mesmo espaço de endereçamento . Por thread (ou
processo leve) entende-se um fluxo de controle independente
dentro do programa [3]. Programas concorrentes são uma al-
ternativa para reduzir o tempo de resposta de aplicações que
possuem alto custo computacional, como por exemplo: quí-
mica quântica, previsão do tempo, simulações, entre outras.
∗ Este trabalho conta com apoio financeiro do CNPq e da FAPESP.
um programa com a intenção de encontrar defeitos e é uma
das atividades que cooperam para garantir a qualidade de soft-
ware [5]. O teste estrutural é uma das técnicas, dentre várias,
que tem foco na estrutura interna (código-fonte) do programa
em teste.
O teste de programas concorrentes, em geral, é abordado a
partir das propostas e conhecimentos adquiridos com o teste
de programas seqüenciais tradicionais. Porém, há desafios
adicionais impostos por características particulares dos pro-
gramas concorrentes, entre elas, o não-determinismo, comu-
nicação, sincronização e concorrência.
Em relação ao teste de programas multithread, a comuni-
cação, que ocorre de forma implícita através do uso de va-
riáveis compartilhadas, torna essa atividade ainda mais com-
plexa. Alguns trabalhos relacionados para tratar o teste estru-
tural de programas multithreads têm sido apresentadas. Essas
propostas podem ser subdivididas de acordo com a forma em
que o programa em teste é executado. São elas: a execu-
ção não-determinística, em que o programa é executado li-
vremente e depois são capturadas informações da execução
para análise [7]; execução determinística, em que, de alguma
forma, é garantida a execução de determinado fluxo de con-
trole e interação entre as tarefas [8, 2]; e uma forma híbrida
denominada teste de alcançabilidade, em que apenas porções
do programa são executadas deterministicamente [4].
No trabalho de Vergilio et al. [7] há a proposta de um
modelo de teste para tratar o teste estrutural de programas
concorrentes que utilizam o paradigma de passagem de men-
sagem. Com base nesses trabalhos, este artigo apresenta o
uso desse modelo de teste para testar programas concorren-
tes que utilizam o paradigma de memória compartilhada. São
discutidas inicialmente características comuns e semelhantes
entre ambos os paradigmas de programação que tornam viá-
vel a aplicação do modelo com poucas modificações.
O artigo está organizado da seguinte forma. Na Seção 2 é
apresentado, em linhas gerais, o padrão Pthread (POSIX Th-
read) e o conjunto de primitivas que foram consideradas neste
trabalho. Na Seção 3 é apresentado o modelo de teste P CF G
(Parallel Control Flow Graph) definido em [7], o qual foi to-
mado como base neste trabalho. Na Seção 4 são mostradas as
considerações feitas a fim de viabilizar a aplicação do modelo
de teste a programas multithreads e na Seção 5 são apresen-
tados os pontos que precisam ser tratados para viabilizar a re-
presentação total de programas multithreads. Por fim, na Se-
ção 6 são apresentadas as conclusões e direções futuras para
o trabalho.
2 Padrão PThread
O PThread (POSIX Thread) é uma biblioteca de threads
que segue o padrão POSIX (IEEE Std 1003.1). Essa bibli-
oteca permite ao programador explicitamente construir um
programa concorrente na linguagem C ANSI. O Pthread de-
fine primitivas para criação e finalização de threads, assim
como diversas primitivas para sincronização (semáforo, mu-
tex e variável de condição). Também fornece diversas outras
funções que permitem, por exemplo, manipular os atributos
de uma thread. No entanto, nenhuma função é fornecida para
realizar a comunicação entre threads uma vez que espera-
se que programas multithreads façam a comunicação através
de variáveis compartilhadas (declaradas no escopo global do
programa).
Neste trabalho decidiu-se abordar apenas o objeto de sin-
cronização do tipo semáforo (sem_t) e as operações sob o
mesmo (sem_init, sem_post e sem_wait), dado sua utilidade
e importância. Futuras extensões deste trabalho deverão tratar
o padrão por completo.
Os semáforos são objetos de sincronização que basica-
mente controlam, dado seu valor, se uma thread deve ou não
seguir sua execução. Ele funciona como um contador de to-
kens que são produzidos e consumidos pelas funções forneci-
das pelo padrão. No Pthread, o semáforo é representado pelo
tipo sem_t que é basicamente uma struct que mantém um
valor inteiro.
A função sem_init é responsável por atribuir o valor inicial
do semáforo. A função sem_post incrementa de um o valor
do semáforo. E a função sem_wait faz o decremento de um no
valor do semáforo se o valor deste for maior que zero, caso
contrário a thread é bloqueada até que seja possível fazer o
decremento. Essas funções, em geral, são indivisíveis a fim
de garantir a integridade do semáforo.
3 Modelo de Teste
O modelo de teste definido em Vergilio et al. [7] trata pro-
gramas concorrentes que utilizam o paradigma de passagem
de mensagem. O modelo de teste é denominado P CF G (Pa-
rallel Control Flow Graph) e tem por objetivo explicitar in-
formações sobre o fluxo de controle, dados e comunicação do
programa concorrente. Esta seção apresenta os conceitos fun-
damentais desse modelo, os quais serão utilizados neste tra-
2
balho. Maiores detalhes sobre esse modelo de teste P CF G
podem ser obtidos em [7].
O modelo considera que o programa concorrente, P rog =
{p0 , p1 , .., pn−1 }, possui um número n fixo de processos e
que n é conhecido estaticamente no momento de execução
do programa. A comunicação entre os processos ocorre por
meio de primitivas send e receive.
O modelo prevê a construção do P CF G pela conexão do
CF Gp (Control FLow Graph) de cada processo p por meio
de arestas de sincronização que representam a comunicação
entre os processos concorrentes. Cada processo p possui um
CF Gp construído usando as mesmas regras definidas para
programas seqüenciais em que nós representam comandos do
processo e arestas representam a transferência de fluxo de
controle [6]. Os nós que representam as primitivas sends e re-
ceives são representados no grafo por nós isolados. As arestas
de sincronização são obtidas ligando os nós que representam
sends aos receives, tal que representem um possível par de
sincronização.
No P CF G o i-ésimo nó do p-ésimo processo é represen-
tado por npi , ou simplesmente ip . O conjunto N denota o
conjunto de nós do P CF G e é dividido em dois subconjun-
tos: Ns conjunto dos nós send e Nr conjunto dos nós receive.
O conjunto E denota o conjunto de arestas. EIp denota o con-
junto de arestas intra-processo pertencentes ao processo p, en-
quanto que Es denota o conjunto de arestas de sincronização
(inter-processo).
Um caminho π p = {npi , ..., npj } no CF Gp é denominado
caminho intra-processo. Quando o caminho possui ao menos
uma aresta de sincronização é denominado inter-processo e
denotado por Π = (π 0 , π 1 , ..., π n−1 ).
O P CF G também evidencia informações de fluxo de da-
dos da mesma forma que ocorre em programas seqüenciais
pela agregação ao grafo de informações de definição de va-
riáveis, e uso computacional (c-uso) ou predicativo (p-uso)
das mesmas. O modelo prevê ainda o uso de comunicação de
variáveis (s-uso).
Por meio desse modelo de teste, o testador pode gerar ca-
sos de teste para executar os caminhos do P CF G e, desse
modo, cobrir informações relevantes sobre o programa con-
corrente.
4 Mapeamento Multithread/PCFG
Esta seção apresenta o mapeamento possível de um pro-
grama multithread, implementado usando a biblioteca Pth-
read, para o modelo P CF G.
Da mesma forma que no modelo de teste definido em Ver-
gilio et al. [7], considera-se aqui que o número n de threads
do programa multithread P C = {t0 , t1 , ..., tn−1 } é fixo e co-
nhecido estaticamente.
Para exemplificar o processo de mapeamento considere o
programa da Listagem 1. Este programa implementa o pro-
blema do produtor/consumidor com buffer limitado. Três th-
 reads participam da computação. A thread mestre (T 0) é res- aresta de sincronização em que o nó 101 representa a função
ponsável por inicializar as variáveis, criar e esperar a finaliza- sem_post (send) e o nó 52 representa a função sem_wait (re-
ção das threads. A thread produtora (T 1) é responsável por ceive).
inserir elementos no buffer e a thread consumidora (T 2) por
consumir os elementos do buffer. Observe que cada instrução
do programa é representada por um nó no grafo. O valor en-
tre comentários (/* e */), ao lado direito do programa, indica o
número do nó no grafo que representa a instrução. A Figura 1
apresenta o P CF G resultante do mapeamento aqui proposto.
Nessa figura as threads mestre, produtora e consumidora es-
tão representadas por T 0, T 1 e T 2, respectivamente.

Listagem 1: Programa do produtor/consumidor com buffer

limitado implementado usando a biblioteca Pthread/C.
1 # include < s t d l i b . h>
2 # include < s t d i o . h>
3 # include < p t h r e a d . h>
4 # include < s e m a p h o r e . h>
5
6 s e m _ t mutex , empty , f u l l ;
7 i n t queue [ 2 ] , a v a l ;
8 /∗ T h r e a d T1 ∗/
9 v o i d ∗p r o d u c e r ( v o i d ) { /∗ 1 ∗/
10 i n t prod = 0 , item ; /∗ 2 ∗/
11 while ( prod < 2) { /∗ 3 ∗/
12 item = rand ()%1000; /∗ 4 ∗/
13 s e m _ w a i t (& empty ) ; /∗ 5 ∗/
14 s e m _ w a i t (& mutex ) ; /∗ 6 ∗/
15 queue [ a v a l ] = item ; /∗ 7 ∗/
16 a v a l ++; /∗ 8 ∗/
17 p r o d ++; /∗ 9 ∗/
18 s e m _ p o s t (& mutex ) ; /∗ 10 ∗/
19 s e m _ p o s t (& f u l l ) ; /∗ 11 ∗/
20 }
21 pthread_exit (0); /∗ 12 ∗/
22 }
23 /∗ T h r e a d T2 ∗/
24 v o i d ∗c o n s u m e r ( v o i d ) { /∗ 1 ∗/
25 i n t c o n s = 0 , my_item ; /∗ 2 ∗/
26 while ( cons < 2) { /∗ 3 ∗/
27 s e m _ w a i t (& f u l l ) ; /∗ 4 ∗/
28 s e m _ w a i t (& mutex ) ; /∗ 5 ∗/ Figura 1: P CF G correspondente ao programa da Listagem 1.
29 c o n s ++; /∗ 6 ∗/
30 a v a l −−; /∗ 7 ∗/
31 my_item = q u e u e [ a v a l ] ; /∗ 8 ∗/ Quanto à função sem_init resolveu-se tratá-la como suces-
32 s e m _ p o s t (& mutex ) ; /∗ 9 ∗/
33 s e m _ p o s t (& empty ) ; /∗ 10 ∗/ sivas chamadas à função sem_post, ou seja, um semáforo que
34 p r i n t f ( " consumed : %d \ n " , my_item ) ; /∗ 11 ∗/
35 } é iniciado com um valor x, terá sua inicialização represen-
/∗ 12 ∗/
tada por x + 1 nós no CF Gt da thread onde ocorre a inici-
36 pthread_exit (0);
37 }
38 /∗ T h r e a d T0 ∗/
39 i n t main ( v o i d ) { alização do semáforo. Por exemplo, é o que acontece com
40 p t h r e a d _ t prod_h , c o n s _ h ;
41 aval = 0; /∗ 1 ∗/ a inicialização do semáforo empty no programa da Listagem
42 s e m _ i n i t (& mutex , 0 , 1 ) ; /∗ 2 , 3 ∗/
43 s e m _ i n i t (& empty , 0 , 2 ) ; /∗ 4 , 5 , 6 ∗/ 1. Empty é iniciado com o valor 2 (linha 43 da Listagem
/∗ 7 ∗/
1) e, portanto, é mapeado em três nós no grafo (nós 40 , 50
44 s e m _ i n i t (& f u l l , 0 , 0 ) ;
45 p t h r e a d _ c r e a t e (& prod_h , 0 , p r o d u c e r , ( v o i d ∗) 0 ) ; /∗ 8 ∗/
p t h r e a d _ c r e a t e (& cons_h , 0 , consumer , ( v o i d ∗) 0 ) ; /∗ 9 ∗/
e 60 ). Tal consideração não muda a semântica da função
46
47 p t h r e a d _ j o i n ( prod_h , 0 ) ; /∗ 10 ∗/
48 p t h r e a d _ j o i n ( cons_h , 0 ) ; /∗ 11 ∗/
49 exit (0); /∗ 12 ∗/ sem_init, pois apesar dessa ser atômica e estar representada
50 }
por x sucessivas chamadas à função sem_post que não são
atômicas, esperasse de um bom programa multithread que,
Para relacionar as funções de sincronização sem_post e de alguma forma, não haja possiblidade de acesso à um se-
sem_wait dos programas multithreads com as funções send máforo sem que esse tenha sido iniciado. Esse mapeamento
e receive dos programas que usam ambientes de passagem de foi feito partindo-se da seguinte analogia: sendo o semáforo
mensagem foi considerada a relação de causa-e-efeito entre considerado um repositório de tokens a serem produzidos e
seus pares [1]. Dessa forma a função sem_post foi mapeada consumidos pelas funções sem_post e sem_wait, respectiva-
para a função send e a função sem_wait para a função receive. mente, a função sem_init pode ser avaliada como a produção
Sendo assim para cada thread t constrói-se seu CF Gt sob (sem_post) sucessiva de x tokens.
as mesmas regras aplicadas aos programas seqüenciais [6]. Apesar do modelo P CF G não tratar a criação de proces-
Os nós que representam funções sem_post e sem_wait são sos, considerando que todos os processos são criados no iní-
mapeadas como nós send e receive, respectivamente. Uma cio da execução do programa concorrente, decidiu-se neste
aresta de sincronização é criada partindo do nó sem_post para trabalho tratar a criação e finalização das threads do programa
todos os nós sem_wait que fazem referência à mesma variá- multithread.
vel semáforo. Por exemplo, a aresta (101 , 52 ) representa uma A função de criação de threads (pthread_create) é tratada

3
como uma função sem_post sob um semáforo arbitrário "cre-
ate_t"(com valor inicial 0) e o primeiro nó do CF Gt é tratado
com uma função sem_wait sob este semáforo. Assim a fun-
ção de criação de threads representa uma sincronização que
informa quando uma thread está apta a iniciar sua execução.
Por exemplo, a aresta (80 , 11 ) representa uma aresta de sin-
cronização relativa à criação da thread t1 .
Tratamento semelhante foi aplicado à função pthread_join
visto que esta faz a sincronização da thread que a chamou
com o fim da execução da thread referenciada. Assim, o nó
que representa a finalização da execução de uma thread (seja
por uma chamada pthread_exit, return, exit, ou algo seme-
lhante) é conectado ao nó que representa a chamada à função
pthread_join sob a thread finalizada. A aresta (122 , 110 ), na
Figura 1, exemplifica uma aresta de sincronização relativa à
finalização de uma thread.
Por fim, agregam-se informações relativas à definição e
ao uso de variáveis (privadas e compartilhadas) ao P CF G,
segundo o modelo proposto.
5 Extensões
O mapeamento de programas multithreads para o modelo
P CF G indica que é factível usá-lo no contexto de programas
multithreads. Para tanto, algumas adaptações são necessárias
a fim de tratar características próprias desses programas.
A primeira adaptação se faz necessária para recuperar in-
formações referentes à comunicação que ocorre em progra-
mas multithreads. Quando são considerados programas con-
correntes com passagem de mensagem, o modelo P CF G
trata ambas as comunicações e sincronizações com o uso das
arestas do tipo s-uso dado que essas arestas associam nós send
a nós receive. Quando há o casamento de sends e receives é
caracterizada uma comunicação e uma sincronização. Assim,
a comunicação é explícita e evidenciada pelo P CF G. Em
programas multithread a ocorrência de uma sincronização
sob semáforos não envolve explicitamente uma comunicação.
A comunicação ocorre implicitamente, por meio de definição
e uso de variáveis compartilhadas, e o modelo P CF G não é
capaz de explicitar essa informação. Por exemplo, os nós 71
(definição) e 82 (uso) no grafo da Figura 1 caracterizam uma
possível comunicação sob a variável queue. Assim, deverão
ser elaborados meios de evidenciar a comunicação.
A segunda adaptação necessária refere-se à ocorrência de
arestas de sincronização intra-thread. O modelo P CF G não
prevê que um processo possa, em um primeiro momento,
enviar uma mensagem e, em um momento subseqüente, o
mesmo processo receber a mensagem. Então as arestas de
sincronização são sempre inter-processos. No entanto, em
programas multithreads é comum que uma thread que faça o
sem_post em um semáforo em seguida faça o sem_wait sob
o mesmo semáforo, ou seja, a mesma thread que produz um
token o consome. Neste caso estaria caracterizada uma aresta
de sincronização intra-thread. Na Figura 1 é o que acontece
se a thread produtora (t1 ) executa o sem_post em mutex (nó
101 ) e na seqüência executa o sem_wait (nó 61 ), caracteri-
zando a aresta intra-thread (101 , 61 ). Essa questão precisa
ser adaptada para completar a representação da sincronização
de programas multithreads por meio do P CF G.
6 Conclusões
Neste trabalho foi apresentada a aplicação do modelo de
teste P CF G em programas multithreads. O teste de progra-
mas concorrentes apresenta dificuldades adicionais devido a
concorrência, não-determinismo, comunicação e sincroniza-
ção, características intrínsecas desse tipo de programa.
Os resultados obtidos com a aplicação do modelo P CF G
no contexto de programas multithreads indicam que é possí-
vel utilizar esse modelo como base para elaboração futura de
um modelo apropriado para esses programas. As adaptações
e extensões apontadas na Seção 5 são necessárias para tratar
particularidades de programas multithreads.
Os próximos passos neste trabalho envolvem o tratamento
de todas as questões levantadas neste artigo com o objetivo
maior de propor um modelo de teste relevante para progra-
mas multithreads considerando também trabalhos correlatos
[7, 8, 4, 2]. Também serão estudados e adaptados os critérios
de teste propostos em Vergilio et al. [7] para o contexto de
programas multithreads. Um protótipo da ferramenta, deno-
minada ValiPthread, para automatizar a aplicação do modelo
está em sua fase inicial de desenvolvimento.
Referências
[1] R. H. Carver and K.-C. Tai. Modern Multithreading: Im-
plementing, Testing, and Debugging Multithreaded Java and
C++/Pthreads/Win32 Programs. Wiley-Interscience, 2005.
[2] O. Edelstein, E. Farchi, E. Goldin, Y. Nir, G. Ratsaby, and S. Ur.
Framework for testing multi-threaded Java programs. Con-
currency and Computation: Practice and Experience, 15(3–
5):485–499, Mar./Apr. 2003.
[3] A. Grama, A. Gupta, G. Karypis, and V. Kumar. Introduction to
Parallel Computing. Addison-Wesley Publishing; 2nd edition,
One Jacob Way, Reading, MA 01867-3999, second edition, Jan.
2003.
[4] Y. Lei and R. Carver. Reachability testing of concurrent
programs. Software Engineering, IEEE Transactions on,
32(6):382–403, June 2006.
[5] R. S. Pressman. Software Engineering: A Practitioner’s Appro-
ach. McGraw-Hill, New York, NY, sixth edition edition, 2005.
[6] S. Rapps and E. Weyuker. Selecting software test data using
data flow information. Software Engineering, IEEE Transacti-
ons on, SE-11(4):367–375, April 1985.
[7] S. R. Vergilio, S. R. S. Souza, and P. S. L. Souza. Cove-
rage testing criteria for message-passing parallel programs. In
LATW2005 - 6th IEEE Latin-American Test Workshop, pages
161–166, Salvador, Ba, 2005.
[8] C.-S. D. Yang and L. L. Pollock. All-uses testing of shared
memory parallel programs. Softw. Test, Verif. Reliab, 13(1):3–
24, 2003.