Como posso testar melhor um programa produtor-consumidor C multithread? [fechadas]

5

Como é melhor escrever testes para um programa C produtor-consumidor multi-threaded?

Eu sei que o GDB pode ser usado para depurar threads, mas acredito que o GDB também pare o thread atualmente sendo depurado enquanto outros threads continuam sendo executados.

Eu quero testar o arremedamento / desbloqueio e o bloqueio mutex apropriados pelos meus threads. Eu olhei em volta muito, mas não consegui encontrar nenhum bom recurso.

Eu tenho testes de unidade para todas as funcionalidades não simultâneas, mas quero ter certeza de que minha simultaneidade está correta. Como os testes de programas multithread podem ser melhor alcançados?

    
por LazerSharks 12.10.2015 / 21:30
fonte

1 resposta

6

A única maneira que conheço para testar software que utiliza a simultaneidade do tipo de bloqueio é testá-los por estresse.

Você pode escrever testes de unidade que abrangem algumas ou até todas as operações que envolvem simultaneidade, mas você ainda não testou realmente seu software, porque os problemas com simultaneidade vêm de interações inesperadas entre threads que são altamente dependentes de tempo e portanto não determinista.

Então, você precisa escrever um teste que execute seu sistema por horas a fio, esperando que, se houver algum problema, ele se manifeste.

É claro que o seu software pode conter um defeito que se manifesta apenas uma vez em um milhão de operações de bloqueio, caso em que, do ponto de vista estatístico, você praticamente não tem nenhuma chance de detectá-lo durante o teste interno. Envie seu produto, e milhares e milhares de usuários começam a usá-lo dia após dia, o tempo todo, e o defeito começa a se manifestar de vez em quando, o que é um pesadelo.

É por isso que a indústria está se afastando da simultaneidade do tipo de bloqueio e usa outras abordagens, como sistemas share-nothing, em que os threads se comunicam apenas por meio de filas de mensagens, por meio das quais passam apenas dados imutáveis. que o único lugar em todo o sistema que envolve o bloqueio é algumas instruções em apenas uma classe, a classe de fila de mensagens. O grande benefício desses sistemas é que eles são testáveis, enquanto os sistemas concorrentes do tipo de bloqueio não são realmente testáveis.

Eles são mais como "teste de estresse e orar".

    
por 12.10.2015 / 23:06
fonte