Analizzando i programmi multithread

voti
7

Abbiamo una base di codice che è di diversi anni, e tutti gli sviluppatori originali sono ormai lontani. Esso utilizza molte, molte discussioni, ma senza apparente design o principi architettonici comuni. Ogni sviluppatore aveva il suo proprio stile di programmazione multithread, in modo da alcuni fili comunicano tra loro utilizzando le code, alcuni dati serratura con mutex, un po 'di serratura con semafori, alcuni l'uso del sistema operativo meccanismi IPC per le comunicazioni intra-processo. Non v'è alcuna documentazione di progetto, ed i commenti sono sparse. È un casino, e sembra che ogni volta che cerchiamo di refactoring del codice o aggiungere nuove funzionalità, introduciamo deadlock o altri problemi.

Così, qualcuno sa di eventuali strumenti o tecniche che aiutano ad analizzare e documentare tutte le interazioni tra le discussioni? FWIW, la base di codice è C ++ su Linux, ma sarei interessato a sapere sugli strumenti per altri ambienti.


Aggiornare

Apprezzo le risposte ricevute finora, ma speravo in qualcosa di più sofisticato e sistematico di consulenza che è essenzialmente aggiungere messaggi di log, capire cosa sta succedendo, e risolvere il problema. Ci sono un sacco di strumenti là fuori per analizzare e documentare il controllo del flusso nei programmi di single-threaded; non c'è niente disponibile per i programmi multi-threaded?


Vedi anche il debug di applicazioni multithread

È pubblicato 13/08/2008 alle 14:09
fonte dall'utente
In altre lingue...                            


7 risposte

voti
4

Come punto di partenza, sarei tentato di aggiungere messaggi di log di tracciamento in punti strategici all'interno dell'applicazione. Questo vi permetterà di analizzare come le discussioni che interagiscono con alcun pericolo che l'atto di osservare i fili cambierà il loro comportamento (come potrebbe essere il caso con il debug step-by-step). La mia esperienza è con la piattaforma .NET e il mio strumento di registrazione favorito sarebbe log4net in quanto è gratuito, ha numerose opzioni di configurazione e, se siete sensibili nel modo in cui si sceglie di implementare la vostra registrazione, non sarà notevolmente ostacolare le prestazioni dell'applicazione. In alternativa, c'è NET di costruito in Debug (o Trace) di classe nel namespace System.Diagnostics.

Risposto il 13/08/2008 a 14:33
fonte dall'utente

voti
1

Una cosa da tenere a mente con l'utilizzo di log4net o un attrezzo simile è che cambiano i tempi di applicazione e spesso possono nascondere le condizioni di gara sottostanti. Abbiamo avuto qualche codice scritto male per eseguire il debug e la registrazione introdotto e questo le condizioni di gara effettivamente rimosso e deadlock (o fortemente ridotta la loro frequenza).

Risposto il 13/08/2008 a 19:27
fonte dall'utente

voti
3

Mi piacerebbe concentrarmi sulle serrature memoria condivisa primi (i mutex e semafori) in quanto hanno più probabilità di causare problemi. Guardate quale stato è protetto da blocchi e quindi determinare quale stato è sotto la protezione di diverse serrature. Questo vi darà un senso di potenziali conflitti. Guardate le situazioni in cui il codice che contiene un blocco chiama a metodi (non dimenticate metodi virtuali). Cercare di eliminare queste chiamate ove possibile (riducendo il tempo si svolge la serratura).

Data l'elenco dei mutex che si tengono e un'idea approssimativa dello stato che proteggono, assegnare un ordine di bloccaggio (cioè, mutex A deve sempre essere presa prima mutex B). Cercate di rispettare questo nel codice.

Vedere se è possibile combinare diverse serrature in uno se la concorrenza non sarà influenzato negativamente. Per esempio, se mutex A e B sembrare potrebbero avere situazioni di stallo e di un sistema di ordinamento non è fatto facilmente, li combinano per una serratura inizialmente.

Non sarà facile, ma io sono per la semplificazione del codice a spese della concorrenza per ottenere un handle del problema.

Risposto il 13/08/2008 a 19:41
fonte dall'utente

voti
6

Investire in una copia di Intel VTune e dei suoi strumenti filo profiling. Vi darà sia un sistema e una vista del livello della sorgente del comportamento thread. Non è certamente intenzione di autodocument la cosa per voi, ma dovrebbe essere un vero aiuto in almeno visualizzare ciò che sta accadendo in circostanze diverse.

Penso che ci sia una versione di prova che è possibile scaricare, in modo da può valere la pena dare che un andare. Ho usato solo la versione per Windows, ma guardando la pagina web VTune ha anche una versione per Linux.

Risposto il 21/08/2008 a 17:38
fonte dall'utente

voti
2

Questo è un problema davvero difficile per strumenti automatizzati. Si potrebbe voler esaminare model checking codice. Non aspettatevi risultati magici: model checker sono molto limitati nella quantità di codice e il numero di thread possono controllare in modo efficace.

Uno strumento che potrebbe funzionare per voi è CHESS (anche se è purtroppo solo per Windows). BLAST è un altro strumento abbastanza potente, ma è molto difficile da usare e non può gestire C ++. Wikipedia elenca anche a vapore , che non ho sentito parlare prima, ma suona come potrebbe funzionare per voi:

Vapore è un correttore modello per C ++. Rileva situazioni di stallo, gli errori di segmentazione, su variabili di intervallo e loop non fatale.

In alternativa, si potrebbe aiutare molto per cercare di convergere verso il codice di un piccolo numero di ben definiti (e, preferibilmente, di alto livello) regimi di sincronizzazione. serrature miscelazione, semafori e monitor della stessa base di codice è di guai.

Risposto il 21/08/2008 a 18:11
fonte dall'utente

voti
1

In Java, avete scelte come FindBugs (per l'analisi statica bytecode) per trovare certi tipi di sincronizzazione incoerenti, o le molte analizzatori filo dinamiche da aziende come Coverity, JProbe, OptimizeIT, etc.

Risposto il 22/09/2008 a 01:19
fonte dall'utente

voti
1

Non può UML aiutare qui?

Se reverse-engineering codebase in UML , allora si dovrebbe essere in grado di disegnare diagrammi di classe che mostra le relazioni tra le classi. A partire dalle classi i cui metodi sono i punti di ingresso del filo, si poteva vedere che thread utilizza quale classe. Sulla base della mia esperienza con Rational Rose , questo potrebbe essere realizzato utilizzando il drag-and-drop; se alcuna relazione tra la classe aggiunto e di quelli precedenti, quindi la classe aggiunto non viene utilizzato direttamente dal thread che è iniziato con il metodo si è iniziato il diagramma con. Questo dovrebbe dà hints verso il ruolo di ciascun thread.

Questo mostrerà anche gli "oggetti" dati condivisi e gli oggetti che sono specifici-thread.

Se si disegna un grande diagramma di classe e rimuovere tutti gli "oggetti dati", allora si dovrebbe essere in grado di layout che diagramma come nuvole, ciascuno nuvole essendo un filo - o un gruppo di fili, a meno che l'accoppiamento e la coesione del codice di base è terribile.

Questo sarà solo ti dà una parte del puzzle, ma potrebbe essere utile; Spero solo che la vostra base di codice non è troppo fangoso o troppo "procedurale", nel qual caso ...

Risposto il 26/09/2008 a 13:25
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more