È sicuro affidarsi all'analisi statica per "riprodurre" in modo affidabile i bug della concorrenza?

Rispondere alla tua prima domanda:

link

"Quali tipi di difetti di concorrenza non viene cercato da ThreadSafe?

• Non includiamo ancora il supporto per tutto java.util.concurrent. In particolare, ThreadSafe non verifica l'utilizzo improprio delle funzionalità avanzate di sincronizzazione fornite da java.util.concurrent, ad esempio il pacchetto java.util.concurrent.atomic. Né attualmente include eventuali pedine per errori che possono verificarsi quando si scrivono programmi paralleli utilizzando il framework Fork-Join.

• Trovare bug in intricati algoritmi senza lock richiede una tecnologia di analisi che non scala bene. Tali algoritmi dovrebbero essere lasciati a esperti specializzati in concorrenza. ThreadSafe può essere configurato per trovare difetti nelle applicazioni che utilizzano librerie contenenti tali algoritmi.

• Le analisi che includiamo nelle nuove versioni di ThreadSafe sono dettate sia da ciò che è possibile utilizzando una tecnologia di analisi sufficientemente matura per l'integrazione in un prodotto utilizzabile, sia dalle caratteristiche e dai difetti di concorrenza che vediamo spesso nella media 'Programmi Java.

• Se si dispone di un problema di concorrenza Java che non è attualmente coperto da ThreadSafe, gli specialisti della concorrenza Java di Contemplate potrebbero essere in grado di aiutare aggiungendo la configurazione personalizzata a ThreadSafe e / o utilizzando una tecnologia di analisi avanzata che non è ancora matura abbastanza per l'integrazione in ThreadSafe. "

Nella mia esperienza, uno sviluppatore determinato, ben intenzionato, ma senza tracce, può avvolgere abbastanza confusione intorno a un bug di concorrenza che lo strumento di analisi mancherà.

Se lo strumento pensa che ci sia un bug, supponi che sia giusto finché non provi il contrario. Questo è il valore dello strumento. Se lo strumento non trova bug, la soluzione migliore è fingere che lo strumento non esista.

Se desideri un codice concorrente affidabile (in qualsiasi lingua), i tuoi obiettivi dovrebbero includere:

1. Le sezioni critiche dovrebbero essere tiny e semplici , quindi sono banali da comprendere.
2. Le sezioni critiche dovrebbero essere completamente isolate da un altro codice a livello di origine.
3. Una funzione / metodo / subroutine coinvolta nel codice concorrente dovrebbe fare solo una cosa . Se manipola una primitiva di sincronizzazione (blocco, semaforo, ecc.), NON deve armeggiare con nessuna delle risorse condivise e NON deve contenere loop o codice condizionale. Sposta il "vero lavoro" in una funzione separata. Questo supporta l'articolo 1.
4. Se hai qualche tipo di blocco, uno sviluppatore dovrebbe essere in grado di leggere il codice e determinare esattamente quale / le risorsa / i che blocca protegge in 30 secondi o meno. Se non è ovvio per te, non sarà ovvio per il prossimo ragazzo. E probabilmente non era chiaro al collega che ha scritto il codice. Quindi probabilmente è rotto.
5. La visibilità della risorsa che stai proteggendo non dovrebbe essere maggiore della visibilità della primitiva di sincronizzazione che la protegge. Nessuno dei due componenti dovrebbe essere visibile al corpo del codice più grande.
6. Ecc. Il resto della lista è in realtà solo una varietà di modi per ripristinare gli articoli 1 e 2.

Se il tuo codice è stato progettato e organizzato correttamente, dovresti essere in grado di esaminare una piccola parte del codice per comprendere e fidarsi della concorrenza. Quando raggiungi questo obiettivo, quindi invia il codice allo strumento di analisi statico e verifica se è d'accordo.

E dai il codice a pochi altri sviluppatori non guru per la revisione. Chiedi loro di spiegare come funziona la concorrenza e perché è corretta. Se non riescono a spiegarlo, è ancora troppo complesso.

La produzione di uno strumento di analisi statica utile comporta il bilanciamento di una serie di problemi contrastanti, inclusi almeno i seguenti:

• Frequenza falsa positiva (falso allarme)
• Percentuale di falso negativo (errore non rilevato)
• Tempo di esecuzione e scalabilità

I falsi positivi sono una preoccupazione fondamentale per gli strumenti di rilevamento dei bug poiché perdono tempo nello sviluppatore. È possibile eliminare i falsi negativi, ma per molti tipi di bug, compresi i bug di concorrenza, ciò comporterebbe un aumento inaccettabile del tasso di falsi positivi. Il tasso di falsi positivi e falsi negativi può essere ridotto al costo di un aumento del tempo di esecuzione, ma le tecniche di analisi più accurate non vanno oltre le piccole applicazioni e comunque non possono essere entrambe ridotte a zero.

Gli strumenti di analisi dinamica spesso richiedono un tasso di falsi positivi dello 0%, ma è perché trovano bug solo una volta che si verificano effettivamente. Per una condizione di gara o deadlock che si verifica solo una volta in una luna blu, non è così utile.

Per questi motivi, ThreadSafe non promette di trovare tutti i bug di concorrenza - mira a trovare quelli più importanti, con un basso tasso di falsi positivi. Alcuni utenti hanno provato ThreadSafe sul codice con un bug noto della concorrenza che impiegano giorni per trovare e scoprono che trova bug - e spesso altri bug genuini di cui non erano a conoscenza - senza falsi positivi, in pochi minuti.

Un buon punto di partenza per informazioni su ThreadSafe è questo articolo InfoQ . Per ulteriori informazioni, consulta il sito Web ThreadSafe dove puoi registrarti per una prova gratuita.

(Disclosure: ThreadSafe è uno strumento commerciale e sono co-fondatore di Contemplate, la società che lo produce.)