Spiegare le condizioni di gara ad un pubblico non tecnico [chiuso]

https://stackoverflow.com/questions/310282

10-07-2019
|

Domanda

Di recente, mi sono ritrovato a dover scrivere alcune preoccupazioni che ho sulle condizioni di gara in un'applicazione che è in fase di sviluppo (non da me). Ciò sarà probabilmente portato all'attenzione delle parti interessate che non sono tecniche e con le quali non ho una linea di comunicazione diretta, quindi la mia spiegazione deve essere in forma scritta.

Ho già provato a scrivere questo articolo. Esaminerò al meglio le specifiche tecniche, fornirò un esempio di come si verificherebbe una condizione di gara nell'applicazione e descriverò il suo impatto. Sento di aver fatto abbastanza bene, ma è tutt'altro che perfetto.

Il problema è che, per quanto provo a proteggere il lettore dall'informatica, ho ancora avuto difficoltà ad eliminare frasi come "fili di esecuzione". e " mutua esclusione " senza perdere correttezza e sostanza. Il rischio è che, con un eccessivo gesto delle mani, queste preoccupazioni possano essere respinte come un truffatore truccato.

Comunque, la mia domanda per te è questa: In che modo tu spiegheresti le condizioni di gara a un pubblico non tecnico? Oseresti spiegare la programmazione della CPU? Invocheresti il ?? filosofi della ristorazione ?

Non devi lavorare nei limiti della mia situazione (ma sarebbe incredibilmente utile se lo facessi).

Soluzione

La società X ha $ 1.000 in banca. X paga un affitto di $ 2.000 e ha ricevuto un pagamento di $ 10.000 per i servizi resi alla società Y. Tuttavia, a causa di una condizione di gara, X è in deficit di $ 1.000 e ora sta richiedendo il fallimento. = (

Potresti voler spiegare in che modo la banca gestisce il conto dell'azienda X in questo modo: il personale bancario A prende il valore attuale di $ 1.000 e aggiunge $ 10.000 ad esso. Il personale bancario B prende il valore attuale di $ 1.000 e ne sottrae $ 2.000. Il personale bancario A aggiorna il valore a $ 11.000. Il personale bancario B aggiorna il valore a - $ 1.000.

Altri suggerimenti

Penso che le transazioni bancarie possano essere un buon esempio, sia perché è facile vedere che un risultato errato è cattivo sia perché le condizioni di gara sono facili da creare in un tale ambiente.

Ho $ 500 sul mio account. Qualcuno mi trasferisce $ 200 contemporaneamente a $ 50.

Ora, se la banca non gestisce correttamente le condizioni di gara, farà quanto segue (supponendo che le transazioni vengano gestite manualmente, ovviamente) L'impiegato A vedrà la richiesta di aggiungere $ 200 al mio saldo e noterà che il mio saldo è attualmente $ 500. L'impiegato B vedrà la richiesta di sottrarre $ 50 dal mio saldo e noterà che il mio saldo è attualmente $ 500 (l'impiegato A non ha ancora trasferito il denaro).

L'impiegato A termina i documenti e imposta il saldo del mio conto su $ 700 (500 + i 200 che avrebbe dovuto aggiungere). E poi, un minuto dopo (perché l'impiegato B ha appena dovuto prendere una tazza di caffè), l'impiegato B termina l'altra transazione e imposta il mio saldo a $ 450 (i 500 che avevo quando ha controllato, meno i 50 che doveva sottrarre ).

Il mio saldo è ora $ 450, quando avrebbe dovuto essere $ 650, a causa di una condizione di gara. Il risultato dipendeva dall'ordine in cui venivano eseguite diverse parti delle due transazioni.

Questa è la descrizione generale di come le condizioni di gara sono cattive. Ora diciamo che invece di commessi, abbiamo la nostra applicazione che elabora due attività separate contemporaneamente (che sono i tuoi 'thread di esecuzione'), e proprio come sopra, entrambi leggono un valore, modificano il valore che essi leggi, quindi riscrivilo. Una delle modifiche potrebbe quindi andare persa se ciò accade nell'ordine mostrato sopra. Ciò dovrebbe essere collegato ai problemi specifici della tua app.

Vorrei un approccio da filosofo da pranzo, ma a seconda del mio pubblico, proverei ad analizzarlo con il contesto del mio pubblico. Stai parlando con i dirigenti aziendali? Quindi analizzalo con qualcosa come assegnare una sala riunioni o un'auto aziendale o prenotare una camera d'albergo o altro. Stai parlando con la gente media? Quindi l'esempio del filosofo del pranzo va bene, oppure puoi pensare a una situazione simile che coinvolga la cura degli animali della fattoria o la seduta su sedie o altro.

Sia che dirottiate l'esempio del filosofo del pranzo, sia che inventiate il vostro, usate sicuramente una metafora.

Se stai scrivendo a un pubblico non tecnico, vorrai semplificare le tue spiegazioni e metterle in relazione con qualcosa che possano capire. Una spiegazione tratta dall'articolo Analogie per insegnare il calcolo parallelo a programmatori inesperti ( http: // portal .acm.org / citation.cfm? doid = 1189136.1189172 ) lo spiega in termini di un gioco di penna:

Giocheremo a un gioco chiamato Gioco della penna. Le regole sono semplici: I & # 8217; m con una penna in mano e quindi dirò & # 8220; Uno, due, tre, vai. & # 8221; Quando dico & # 8220; vai, & # 8221; prendi la penna dalla mia mano. Chi prende la penna vince. Pronto? Uno, due, tre, vai.

Quindi chiedi se il risultato di questo gioco può essere previsto in anticipo. Se non è possibile prevederlo, possiamo garantire un risultato corretto? Ciò dovrebbe portare alla consapevolezza che è possibile ottenere risultati errati per scritture simultanee nello stesso pezzo di memoria.

Stavo per consigliare i filosofi della sala da pranzo, ma vedo che l'hai già trovato. Quindi, in alternativa, che ne dici di usare gridlock come un'analogia?

Immagina il normale traffico che guida lungo le quattro strade vicino a un singolo isolato (North ave, South ave, East street e West street). Quando ci sono solo una o due auto sulla strada, tutto si muove senza intoppi. Quando il traffico è costante, alcune auto dovranno fermarsi e attendere che altre vadano oltre, ma questo è un problema gestibile. Un'auto si ferma per aspettare che passi un'altra, quindi continua per la sua allegria.

Ora, traffico di foto nelle ore di punta nella stessa posizione. Diciamo che una macchina che guida a sud su West street non può attraversare l'incrocio all'angolo nord-ovest del nostro isolato. Quell'auto ora blocca tutto il traffico trasversale in direzione ovest su North Ave. Non ci vuole molto prima che un'auto in direzione ovest provi a superare l'incrocio all'angolo NorthEast e si blocchi, bloccando tutto il traffico in direzione nord su East street. Quando questa situazione arriva fino ai quattro incroci, nessuna macchina può muoversi! Ognuno sta aspettando che le macchine che la precedono si muovano in avanti, ma non c'è modo di recuperare il parapetto senza tirare indietro le macchine.

Il confronto con l'informatica dovrebbe essere semplice. Le auto sono thread o processi, strade e viali sono processori, buffer o core. Il concetto di blocco può essere descritto usando semafori o segnali di stop e il tutto inizia a dare un senso intuitivo, anche ai non programmatori.

Scrivi un programma:

Aspetta il salario.
Vai al negozio.
Compra cibo.
Accendi il piatto.
Metti il ??cibo nel piatto.
Conserva la piastra per 20 minuti.
Mangia.
Vai a letto.

Ora prova a far eseguire due thread (tu, moglie) senza sincronizzazione.

Tu: aspetta lo stipendio.
Moglie: vai al negozio senza soldi, schianto
Tu: accendi il piatto.
Tu: mantieni la piastra per 20 minuti.
Tu: vai a letto.
Moglie: mangia a casa di qualcun altro.
Moglie: vai a letto.

Peter vuole uscire dal suo vialetto. Verifica che non ci siano ostacoli sulla sua auto, poi entra. Suo figlio Frank si nasconde dietro la macchina. Peter non riesce a vederlo e lo investe.

La cosa importante qui è che per un computer, "ispezionare" e " modifica " tendono ad essere due azioni separate, quindi un esempio in cui non puoi controllare qualcosa quando lo modifichi è una buona scelta.

Che ne dici del semplice ovvio?

Una condizione di razza è letteralmente una gara tra due persone.

Una società sta facendo offerte per un progetto. Due dipendenti che lavorano in modo indipendente sulle offerte li inviano al cliente, ma uno dei dipendenti ha informazioni obsolete. Nessuno dei due dipendenti sa che l'altro è in procinto di presentare un'offerta, quindi a seconda di chi è più veloce, la prima offerta può essere sostituita con il dipendente più lento. Ciò causerà confusione poiché l'offerta potrebbe essere cambiata nel tempo.

È necessario che vi sia comunicazione tra i due dipendenti per lavorare insieme o fermarne uno.

Una difficoltà nello spiegare il concetto generale è che le condizioni razziali si manifestano in un'ampia varietà di situazioni. Se il tuo obiettivo è dare al tuo pubblico non tecnico la sensazione che si tratti di un tipo di problema generico, dovresti provare a offrire più di un esempio.

Un'immagine vale più di 1000 parole. È vero. Se si disegna una linea temporale e si inserisce un'entità su di essa e si mostrano i suoi cambiamenti di stato con il passare del tempo, è possibile dimostrare abbastanza facilmente una condizione di gara in un diagramma. Potrebbero essere necessari alcuni rifacimenti per ottenere l'immagine giusta, ma ho sempre scoperto che disegnarla ottiene il mio punto di vista deve essere più veloce di descriverla.

Penso che sia difficile spiegarlo in modo semplice, perché pensare alla concorrenza è intrinsecamente difficile. L'idea di base di una transazione finanziaria potrebbe essere un buon punto di partenza, poiché le persone avranno una certa familiarità con loro dalla vita reale.

In qualsiasi tipo di transazione, è necessario effettuare registrazioni simultanee in due posizioni: debiti e crediti. Se la transazione viene interrotta nel mezzo da qualcun altro che tenta di eseguire un'altra transazione, vedrà il saldo errato in uno o nell'altro dei conti.

C'è un ottimo esempio in Programmazione concorrente strutturata con applicazioni dei sistemi operativi ( come ricordo)

Nel paese impoverito del Bezerkistan, due linee si fondono su una sola traccia in un tunnel. Ci sono state collisioni e la giunta al potere ha bisogno di una soluzione.

Il problema è che è montuoso e gli ingegneri sono ciechi. C'è pochissimo preavviso per due treni che stanno per scontrarsi nel tunnel.

Ecco il piano.

Metti una grande ciotola nel punto di congiunzione.
Dai a ogni ingegnere una scimmietta in ottone.

Quando stai per entrare nel tunnel, fermi il treno. Batti una pacca nella ciotola per vedere se una scimmia di ottone è nella ciotola.

Se c'è una scimmia, qualcun altro sta usando il tunnel, quindi devi aspettare fino a quando il loro treno è completamente nel tunnel, a quel punto il conduttore esce dal caboose e prende la scimmia dalla ciotola.

Se non c'è scimmia, nessun altro sta usando il tunnel. Quindi, puoi prendere la tua scimmia dal vano motore, metterla nella ciotola e guidare attraverso il tunnel, sapendo che hai acquisito l'accesso esclusivo alla pista. Naturalmente, ti fermi brevemente per consentire al conduttore di recuperare la scimmia d'ottone.

Indovina un po '?

Hanno ancora avuto collisioni!

Perché? Qual è la situazione o la sequenza di azioni che ne fanno fallire?

Questa è una condizione di gara.

In un documento scritto, puoi spiegare come le condizioni di gara portano a un incidente.

In una presentazione, puoi guidare il pubblico attraverso il ragionamento su concorrenza e blocco.

Vorrei utilizzare un esempio di conto bancario con memoria condivisa di una condizione di competizione dati.

spiega che il computer fa qualcosa di simile: bilanciamento del carico; aggiungere 1; saldo del negozio ;. prendi in considerazione due discussioni che stanno modificando il saldo del tuo conto bancario (tu e tua moglie state entrambi depositando un dollaro contemporaneamente).

se entrambi i thread vengono interrotti dopo il: bilanciamento del carico; e poi riprendi, puoi perdere un dollaro.

vedi: http://wasp.cs.washington.edu/atomeclipse/handouts .pdf

Come hai già detto, spesso devi introdurre altri concetti (mutua esclusione, fili di esecuzione) per descrivere accuratamente le condizioni di gara, anche in una metafora. Quindi prova a definire questi termini (o almeno a far passare l'idea) prima, usando la metafora.

Come semplice esempio, usiamo un incrocio a 4 vie (impostato in un paese in cui guidi a destra). Dividi l'intersezione in 4 quadranti: nord-ovest, nord-est, sud-est e sud-ovest. Ora chiama ogni quadrante una risorsa e chiama ogni macchina un thread di esecuzione. Queste auto rispettano solo i sistemi di traffico e poiché non ci sono segnali di stop o semafori a questo incrocio, le auto si muovono a destra senza rallentare o considerare il traffico.

Puoi facilmente dimostrare che l'uso simultaneo di uno di questi quadranti da parte di più di un'auto è negativo e provoca un incidente d'auto. Una soluzione ovvia è installare un sistema di traffico. Il sistema garantisce che non più di un'auto attraversi un quadrante contemporaneamente. Può farlo in modo complicato, senza legare tutte le risorse. Ad esempio, lasciando che le auto provenienti da sud girino a sinistra per dirigersi verso ovest (usando i quadranti sud-est e nord-ovest), mentre lasciando che le auto provenienti da ovest girino a destra per dirigersi verso sud (usando il quadrante sud-ovest) . Il sistema del traffico prevede l'esclusione reciproca o impedisce l'uso simultaneo (da parte di più auto) di una risorsa comune (il quadrante della strada nell'intersezione).

Questo almeno fornisce le idee alla base di queste definizioni, l'idea che l'accesso simultaneo alle risorse condivise può essere negativo e che l'esclusione reciproca può risolvere questo problema. Dopo che questo è stato stabilito, dovrai mapparli su una metafora più appropriata per mostrare quale sia una condizione di razza e come sia una di quelle cose cattive che deriva dalla mancanza di esclusione reciproca per una risorsa comune.

Ci vuole un po 'più di tempo, ma garantisce una certa familiarità con i termini e il quadro generale prima di approfondire una metafora più complessa.

Parlare di soldi con i tuoi stakeholder potrebbe portarli in modalità panico, specialmente se ritengono che stiano perdendo soldi reali a causa di ciò, il che non è esattamente l'ideale se il problema non si traduce in una perdita netta di profitti, quindi ecco un storia meno orientata finanziariamente su come spiegare una condizione di razza a chiunque.

Questa storia non affronta il concetto di deadlock , ma lo scenario e le conseguenze delle condizioni di gara più tradizionali.

LA STORIA INIZIA QUI:

L'impostazione: ci sono 3 città collegate da una rete ferroviaria. I treni non hanno alcun segno su di essi che indica da quale città provengono e in quale città stanno andando perché vengono utilizzati tra tutte e 3 le città e la rete ferroviaria non ha voluto affrontare la seccatura di cambiare i segni tutti tempo. Poiché la rete è piccola, non vi è alcun programma concreto su quando i treni arrivano e partono. I sorveglianti delle stazioni ricevono una chiamata dagli altri sorveglianti delle stazioni urbane quando un treno parte, il sorvegliante prende nota del tempo in cui è partito e poiché tutti i treni sono gli stessi modelli guidano alla stessa velocità, quindi quando il sorvegliante riceve una chiamata dalle altre città che annunciano alle persone nella stazione che: "Il prossimo treno si dirigerà verso la città C". Quindi le persone che desiderano viaggiare verso la città C attendono il treno, salgono e viaggiano allegramente verso la città C.

Il problema: Ma un giorno, mentre un treno stava pianificando il suo percorso da A a B a C, si è rotto a metà strada tra A e B. Fortunatamente i tecnici sono molto abili e essere in grado di riparare il treno in breve tempo. Tuttavia, quello stesso giorno un altro treno stava pianificando un percorso diverso da C a B verso A. Il sorvegliante alla stazione B ricevette una chiamata da A che stava arrivando un treno, e poco dopo ricevette un'altra chiamata da C che stava arrivando anche un altro treno. Il sorvegliante della stazione annunciò quindi ai passeggeri in attesa nella stazione: "Il primo treno in arrivo sarà diretto alla stazione C, e poco dopo il treno si dirigerà alla stazione A." Mentre i passeggeri raccoglievano i bagagli e si dirigevano verso le rispettive piattaforme. Il sorvegliante vide arrivare un treno e reindirizzò le rotaie verso il binario dove la gente stava progettando di dirigersi verso la città C. Non sapevano che invece il treno sarebbe effettivamente andato nella città A. L'altro treno, dopo aver risolto i suoi "problemi meccanici", arrivò anche alla stazione e il sorvegliante lo diresse felicemente alla piattaforma contenente passeggeri che desideravano andare in città A. Inutile dire che nessuno dei passeggeri arrivò dove avevano programmato, tutto perché il il sorvegliante supponeva che sarebbero arrivati ??in ordine come al solito.

Il problema con le condizioni di razza e molti costrutti dell'informatica è che le persone non sono computer. Ogni volta che spiego un algoritmo ai miei studenti dicono "ma non ha senso farlo in quel modo", a cui rispondo "i computer non hanno buon senso, tutto quello che hanno sono istruzioni". A parte questo, dovresti spiegare una condizione di gara come gara, e ha molto senso lasciare che le persone provino effettivamente la gara, se possono. In questo modo possono vedere come le cose vanno male. Ma ... non è loro permesso usare il buon senso.

Quindi supponiamo di avere un gioco in cui 2 persone riempiono pile di blocchi colorati in ordine Rosso, Arancione, Giallo. Hanno molti blocchi rossi, arancioni e gialli. Tutte le pile devono essere alte esattamente tre blocchi.

Nel primo gioco entrambi cercano di farlo il più velocemente possibile, ma funzionano solo sulle proprie pile.

Nel secondo gioco provano a lavorare insieme permettendosi di impilare blocchi l'uno sull'altro. Tuttavia, non sono autorizzati a cambiare il blocco che hanno in mano e devono posizionare un blocco pianificato.

Puoi immaginare una situazione come questa nello stack 1:

player 1 grabs a red block
player 1 places red block         - player 2 grabs an orange block
player 1 grabs an orange block    - player 2 places an orange block
player 1 places an orange block

Quindi ora abbiamo uno stack con due blocchi arancioni. È ovvio che con un gioco umano ciò non accadrà mai, perché le persone hanno buon senso: vedono che il blocco arancione è già posizionato e annullano la loro decisione di posizionare anche un blocco arancione.

Inoltre puoi mostrare loro questo video: https://www.youtube.com/watch? v = TcGwNdbsAbc

Usiamo una lavagna per svolgere un'attività di contabilità banale. Abbiamo $ 100 a portata di mano: scrivilo sulla lavagna.

Alice ha dozzine di fatture che ammontano a $ 100, quindi noterà che $ 100, andrà ad aggiungere la sua lista e tornerà tra 5 minuti e scriverà $ 200 alla lavagna.

Bob ha fatto la spesa. Prende quel numero dalla lavagna e va a sottrarre $ 50 di acquisti, quindi scriverà $ 50 sulla lavagna.

Se Bob torna per primo, vedremo $ 200 dopo che Alice ha scritto il suo risultato. Se Alice torna prima vedremo $ 50, anche sbagliato. Quello che vogliamo è di $ 150 e dobbiamo aggiungere alcune precauzioni da qualche parte per farlo accadere.

Questo dovrebbe essere sufficiente per impilare una discussione di soluzioni tecniche con intuizioni ragionevoli.

Ad esempio, un mutex significa che chiudi la porta della stanza con la lavagna e fai in modo che facciano il loro lavoro. Una soluzione ottimistica significa che entrambi possono controllare e ricominciare da capo se il numero è cambiato mentre erano assenti. Se vuoi parlare di deadlock, puoi ridere di Bob che chiama Alice dalla stanza chiusa per chiederle di sbrigarsi.

Inviali a Condizioni di gara su Wikipedia.

La prima parte avrà un senso, e il resto (non mostrato di seguito) ti farà sembrare intelligente poiché presumono che tu lo capisca.

" Una condizione di gara o un pericolo di gara è un difetto in un sistema o processo in cui la produzione e / o il risultato del processo dipendono inaspettatamente e criticamente dalla sequenza o dalla tempistica di altri eventi. Il termine ha origine dall'idea di due segnali che si corrono l'un l'altro per influenzare prima l'uscita. & Quot;

Penso che il punto chiave da superare sia che è più frequentemente un problema di tempistica che può essere imprevedibile perché di volta in volta il tempo che qualcosa cambia differisce

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow