Approaches to Concurrency [closed]

Question

Approaches to Concurrency [closed]

#1 da (1 voti)

-1

Ho fatto delle ricerche sui vari approcci alla concorrenza, e ho finito con la seguente tassonomia:

Concorrenza manuale basata su thread con blocchi
Code e callback di distribuzione asincrona implementati in libdispatch (GCD) di Apple
Funzioni asincrone, blocco e trasmissione del messaggio come costrutti del linguaggio di prima classe implementati in Go
Concorrenza funzionale in cui l'immutabilità rende la parallelizzazione quasi automatica come implementata in Haskell, Clojure, ecc.

Ovviamente questa non è una tassonomia "pura" (dato che alcuni elementi sono costruiti sopra altri), ma sembra corrispondere ai paradigmi adottati dalle persone e dalle lingue per scrivere codice reale, utile (cioè non documenti accademici) .

Supponendo che la mia lista sia corretta, sto cercando un veterano della concorrenza grizzled per darmi una breve carrellata sui pro e contro di ciascuno.

Ad esempio, molte persone tendono a considerare i thread difficili da gestire, ma apprezzano che sono un costrutto di basso livello che può essere altamente performante se ti puoi permettere il tempo di sviluppo. Sto cercando quel livello di dettaglio sugli altri 3 e qualsiasi confronto pertinente tra loro.

concurrency multithreading

posta ebrts 23.11.2015 - 21:49

fonte

1 risposta

Leggi altre domande sui tag concurrency multithreading

In che modo gli sviluppatori front-end testano le pagine quando i file che vengono consegnati sono viste PHP? [chiuso] Confronto tra Red / Black Tree e Java ArrayList, quali sono i vantaggi di ciascuno? [chiuso]

score 1 · Answer 1

Il fatto che alcuni ambienti mescolino e abbinino alcuni approcci complica inutilmente la discussione, quindi è meglio lasciarlo fuori. Le funzioni asincrone sono in gran parte equivalenti al passaggio di messaggi (solo una sintassi più comoda), quindi non devono essere considerati come una categoria separata.

Quindi, i quattro approcci che hai elencato possono essere riformulati come solo tre:

Sincronizzazione con i blocchi.
Passaggio del messaggio.
Concorrenza funzionale.

La sincronizzazione con le serrature tende a produrre design eleganti che sono espressi con un numero minimo di linee di codice. Il problema è che sono molto difficili da eseguire il debug, ed è impossibile garantire la loro correttezza, perché non sono testabili. Il tuo programma potrebbe contenere un difetto correlato alla tempistica che si manifesta solo una volta su un milione di operazioni, il che significa che non hai praticamente nessuna possibilità di scoprirlo durante i test interni, ma una volta spedito il tuo prodotto a milioni di utenti in tutto il mondo, che lo stanno esercitando tutto il giorno, il difetto inizia a manifestarsi da qualche parte sul pianeta ogni pochi minuti o giù di lì, ed è allora che inizia il tuo incubo. La non testabilità significa che non importa quello che fai, nel momento in cui spedisci il tuo prodotto non puoi essere certo che non si trasformerà in un tale incubo.

Il passaggio dei messaggi tende a richiedere più codice, ma è più facile eseguire il debug e, soprattutto, è testabile. Ciò significa che una volta che il sistema funziona, è possibile che continui a lavorare senza sorprese. Certo, questo richiede un po 'di disciplina, ad esempio assicurandosi di non passare mai nulla di mutevole nei messaggi, ma con gli strumenti adeguati questo è qualcosa che può essere applicato e non lasciato al caso.

Per quanto riguarda la concorrenza funzionale, vediamo se qualcuno che ha un'esperienza reale con esso può dirci alcuni dei suoi pro e contro. Uno svantaggio che so è che è difficile eseguire il debug, perché è difficile impostare un punto di interruzione su una sottoespressione o un passo singolo in una sottoespressione, anche se mi aspetto che si tratti di una limitazione di debugger e debugger dovrebbe davvero migliorare in questo.