Supponiamo di trovarci in un ambiente distribuito e l'esclusione reciproca non è ancora stata implementata. Quindi, come potremmo essere in grado di rilevare le condizioni di gara?
Quando ho cercato, l'uso di algoritmi non bloccanti è stato trovato come soluzione. Questo sta usando le strutture di dati come stack, code, ecc. In modo da evitare l'esclusione reciproca.
Ma come lo rileviamo?
Comportamento anomalo. Come aggiornamenti incoerenti. Come deadlock Come succede a cose strane.
Sfortunatamente, il debug di un comportamento anomalo è DIFFICILE. Non hai modo di sapere, oltre all'esperienza, se hai a che fare con una condizione di competizione o qualcosa di più banale.
Questo è il motivo per cui progetti le condizioni della gara, all'inizio. Questo è il motivo per cui tu definisci l'esclusione reciproca, o qualcos'altro che realizza fini simili, nel tuo sistema, fin dall'inizio.
Questo è anche il motivo per cui i sistemi operativi erano una classe richiesta. È stato quello che ti ha insegnato sui problemi di concorrenza, incluse le condizioni di gara, la situazione di stallo e la necessità di un'esclusione reciproca.
C'è una condizione di competizione ogni volta che esiste la possibilità che una risorsa acceda contemporaneamente a due o più entità. L'accesso implica,
Se una lettura / scrittura avviene simultaneamente come segue
| Thread A | Thread B | Problem? |
--------------------------------------------------------------------------
| Read | Read | No |
| Read | Write |There is a problem if A reads an obsolete value |
| Write | Read |There is a problem if B reads an obsolete value |
| Write | Write | There IS a problem. The final value will |
| | | depend upon the last value written/over written |
Prima dell'esecuzione:
Per individuarlo in un pezzo di codice occorre esperienza per capire se la risorsa verrà modificata in tal modo Devi pensare in tutte le direzioni possibili e sviluppare casi di test per lo stesso
Dopo (diverse) esecuzioni:
Devi tenere gli occhi aperti per qualsiasi risultato inaspettato / non spiegato. Ci sono possibilità che il problema si trovi altrove, ma è necessario verificare se c'è un accesso simultaneo da qualche parte nel codice
Supponendo che tu non voglia veramente rilevare condizioni di gara (che IMHO è difficile con o senza esclusione reciproca disponibile), ma voglio solo evitarle: se il tuo sistema non ti fornisce qualche tipo di Mutex out-of-the-box, puoi implementare il tuo. Wikipedia attualmente elenca cinque diversi algoritmi (per una soluzione software), scegli il tuo preferito. Naturalmente, Wikipedia afferma anche che questi algoritmi non funzionano in un ambiente di esecuzione fuori uso, bat che è un problema speciale del tuo hardware e del compilatore che stai usando.
Le condizioni di gara saranno con noi fino a quando le persone creano programmi software .
Nessuna best practice ti proteggerà completamente dalle condizioni di gara, perché l'uso corretto delle migliori librerie e delle migliori pratiche coinvolge ancora gli umani e un errore cognitivo umano in tutte le fasi, progettazione, implementazione, test, supporto.
Abbiamo utilizzato i seguenti principi:
Primo: Abbiamo appreso che il tuo migliore amico è uno strumento di analisi dinamica sofisticato sempre attivo , che analizza ogni esecuzione della tua applicazione. (Pensa al tempo e al risparmio energetico, perché sprecare l'energia nell'esecuzione dei processi software?)
Secondo: Fai in modo che il tuo utente sia il tuo tester. Cioè rilasciare il prodotto con un agente che esegue l'analisi in fase di esecuzione. Ciò accorcia i tempi di commercializzazione, poiché avrai la certezza che qualsiasi errore mancato durante la prova della condizione di gara verrà analizzato in tempo reale e che lo saprai prima che l'utente lo faccia.
Terzo: Rendi i problemi identificati dall'agente giungere alla tua console in tempo reale.
Forth: Fai che il tuo agente esegua analisi complete e dettagliate in tempo reale e in modo completamente automatico. Quindi non dovrai mai preoccuparti che il programmatore non esegua analisi errate, anche se il tuo programmatore è stato fortunato a ricreare la gara condizione (spesso una proposta molto difficile). La ricerca di Microsoft mostra che oltre il 30% dell'analisi delle condizioni di gara (rilevate) (dagli umani) è stato eseguito in modo errato.
Quinto: Se l'analisi viene catturata da sola con le informazioni dinamiche del sistema , non dovrai mai preoccuparti di essere in grado di riprodurre il problema.
Sei: 100 agenti sono meno costosi e più affidabili di 100 tester umani. Quindi, se la tua console riceve risultati aggregati da 100 (o più) agenti, il tuo componente Time-To-Market influenzato dal tuo test ha ottenuto solo 100 (o più) tempi più brevi.
E Seven: Se l'analisi dell'agente viene spiegata al livello del codice sorgente (mentre l'agente analizza in realtà il codice e nessun codice sorgente viene fornito o disponibile al momento dell'analisi) i tuoi "Black Box Tester" diventano "White Box Testers" durante la notte.
PS: non è solo un'opinione, ma un'esperienza personale consentita dall'uso degli strumenti creati da TinkingSoftware.com
Dichiarazione di non responsabilità: non sarei in grado di fornire una risposta così dettagliata se non fossi coinvolto nella creazione e nell'utilizzo di questo strumento, "Race Catcher", e questo servizio, "ARM-CM", rappresentasse il monitoraggio dell'affidabilità delle applicazioni tramite le macchine collaborative .
Leggi altre domande sui tag operating-systems concurrency