Test unitari, deadlock e condizioni di gara

Question

Qualche suggerimento su come scrivere test unit ripetibili per il codice che può essere suscettibile a deadlock e condizioni di gara?

In questo momento mi sto sporgendo per saltare i test unitari e focalizzarmi sugli stress test. Il problema è che puoi eseguire uno stress test 5 volte e vedere cinque diversi risultati.

EDIT: so che probabilmente è solo un sogno, ma se ci fosse un modo per controllare i singoli thread e indurli a eseguire un'istruzione alla volta, potrei arrivare da qualche parte.

Answer 1

Dai un'occhiata a TypeMock Racer (è in Beta)

modifica: in realtà Alpha

http://www.typemock.com/Typemock_software_development_tools.html

Answer 2

Di solito è possibile forzare previste condizioni di gara e deadlock usando cose come ManualResetEvent per portare ogni thread nello stato previsto prima di rilasciarlo - cioè ottenere thread A per avere il blocco e attendere un segnale ... ottenere il thread B per richiedere il blocco, ecc ...

Tuttavia, in genere è possibile scrivere un test di questo tipo per indagare su un sospetto bug, per dimostrare quando è stato risolto e che non si ripresenta. Generalmente progetteresti intorno alle condizioni di gara (ma testale al meglio quanto è pragmatico).

Answer 3

Non credo che la ricerca delle condizioni di gara rientri davvero nel regno dei test unitari. Più o meno per definizione, l'unico modo per testare le condizioni di gara è pseudo-casuale. A meno che tu non sia disposto a impegnarti per dimostrare formalmente la correttezza della tua strategia di blocco, dovrai fare alcuni test di stress.

Devi ancora scrivere unit test, per verificare la correttezza degli algoritmi, piuttosto che la strategia di blocco.

Quando si esegue lo stress test del codice multi-thread, si consiglia di eseguire il test in condizioni in cui si dispone di una CPU per thread, in cui sono presenti più thread che condividono la CPU e in cui si hanno più CPU che thread (se possibile).

Answer 4

È possibile scrivere una classe di blocco che rilevi potenziali deadlock, osservando l'ordine delle operazioni di blocco. Lo facciamo avendo un contesto di thread con cui tutti i blocchi si registrano quando vengono acquisiti (può essere fatta solo un'opzione DEBUG).

L'idea è quella di creare un grafico in cui i nodi rappresentano i blocchi e un bordo diretto tra A e B significa che il blocco A è stato trattenuto quando è stato acquisito il blocco B '. Lascia che il tuo programma venga eseguito utilizzando carichi normali, quindi controlla i cicli nel grafico. Un ciclo significa che esiste un potenziale deadlock anche se il tuo codice non lo ha raggiunto.

Answer 5

Non riesco a pensare a un buon modo automatizzato, ma il più vicino a cui sono venuto è stato scrivere un test unit che avrebbe "esposto" un deadlock usando i breakpoint oltre a un unit test. Ho semplicemente aggiunto alcune istruzioni su dove aggiungere il breakpoint. C'è qualche sforzo manuale in gioco, ma con loro puoi sempre esporre il tuo programma di discussione del caso peggiore.

Forse qualcuno ha trovato un buon modo per automatizzare questo tipo di funzionalità? Potrei immaginare di eseguire automaticamente il debugger, rompere un thread su una riga specifica, lasciarne un altro correre fino a una condizione specifica, quindi affermare per il test dell'unità.

Answer 6

Ho precedentemente usato ritardi artificiali nel codice che sono stati attivati ??da alcuni parametri nella richiesta. Ad esempio, una richiesta indica al server di ritardare la scrittura tra due scritture e un'altra per eseguirle senza ritardi tra.

Scrive Mark Bessey, questo è utile solo per creare repro, non per scoprire il problema.

Answer 7

Hai provato Corensic Jinx ?