Perché dovrei conoscere la programmazione concorrente?

Ecco una motivazione rapida e semplice: se desideri codificare qualsiasi cosa tranne i sistemi più piccoli e deboli, scriverà codice simultaneo.

Vuoi scrivere per il cloud? Le istanze di calcolo nel cloud sono piccole. Non ne hai di grandi, ne hai molti piccoli. Improvvisamente la tua piccola app web è un'app concorrente. Se lo hai progettato bene, puoi semplicemente aggiungere più server man mano che ottieni clienti. Altrimenti, devi imparare come la tua istanza ha il suo pegging con carico medio.

OK, vuoi scrivere app per desktop? Tutto ha una CPU dual-or-more-core. Tranne le macchine meno costose. E le persone con le macchine meno costose probabilmente non stanno andando a sborsare per il tuo software costoso, vero?

Forse vuoi fare lo sviluppo mobile? Ehi, l'iPhone 4S ha una CPU dual-core. Il resto non sarà molto indietro.

Videogiochi? Xbox 360 è un sistema multi-CPU e la PS3 di Sony è essenzialmente un sistema multi-core.

Non puoi semplicemente scappare dalla programmazione concorrente a meno che tu non stia lavorando su problemi piccoli e semplici.

Aggiornamento 2016 : l'attuale iterazione del Raspberry Pi da $ 35 è basata su un sistema quad-core su un chip destinato ai telefoni cellulari. I progressi drammatici nell'IA sono stati in parte dovuti alla disponibilità di schede grafiche di fascia alta come motori di calcolo paralleli.

Dal 1970 a circa il 2002 i processori hanno raddoppiato la velocità ogni 18 mesi. Quindi, come programmatore, tutto ciò che dovevi fare era aspettare e il tuo programma sarebbe andato più veloce. Il problema è che intorno al 2002 le regole sono cambiate. Ora non stanno facendo processori veloci più grandi, stanno facendo processori più piccoli ma più lenti ma li mettono in gruppi. Il computer su cui sto lavorando ora ha 4 core e esistono chip con fino a 8 core (e 4 thread per core). Presto avremo chip con molti più core.

Quindi, se scrivi un programma che non è affatto concorrente, scoprirai che stai usando 1 core o thread, ma il resto della CPU è seduto lì senza fare nulla. Quindi se hai 16 core 1 eseguirai il tuo programma e gli altri 15 sono lì seduti!

Il problema con la concorrenza è che non è deterministico. Il che vuol dire che non si sa esattamente quale ordine faranno le diverse discussioni. Tradizionalmente i programmatori hanno provato a risolverlo usando serrature e simili. Questo ha portato a un LOT di dolore. Avere una forma di stato mutabile che più di un thread può accedere liberamente è spesso una formula per il dolore e heisnebugs!

Di recente la tendenza è quella di passare a linguaggi funzionali che controllano strettamente lo stato mutabile. Esistono due modi fondamentali in base ai quali i linguaggi funzionali gestiscono la concorrenza. Il primo è usando il passaggio dei messaggi. Questo è meglio mostrato da Erlang. In Erlang non c'è in generale nessuno stato condiviso tra i processi. Comunicano non condividendo la memoria ma i miei messaggi di passaggio. Questo dovrebbe avere senso per te come lo stiamo facendo adesso. Ti sto mandando queste informazioni inviandoti un messaggio, non ricordandoti di averlo dimenticato dal mio cervello! Passando al messaggio che passa la maggior parte dei bug di blocco semplicemente se ne vanno. Inoltre i messaggi possono essere passati sulla rete e all'interno di un nodo.

L'altro metodo è STM, che sta per Software Transcriptional Memory, presente in clojure e Haskell (e altri). Nella memoria STM è condivisa ma le modifiche possono essere apportate solo tramite una transazione. Dato che la gente del Database ha capito tutto questo negli anni '70, è abbastanza facile assicurarsi di aver capito bene.

In realtà ho semplificato un po ', Clojure e Haskell possono entrambi passare il messaggio ed Erlang può fare STM.

Dichiarazione di non responsabilità Sono l'autore di Programmazione di servizi Web con Erlang , che sarà disponibile nella versione iniziale in prossime settimane.

Perché la concorrenza può esplodere in faccia quando ti aspetti il minimo ...

La prima regola della programmazione simultanea è "È difficile". La seconda regola della programmazione simultanea è "It. Is. Difficult" .. !!

Seriamente, ci sono due approcci comuni alla programmazione simultanea, multi-threading e multi-processing. La multielaborazione è la più semplice da comprendere poiché significa semplicemente disporre di più istanze di un processo in esecuzione per eseguire un'attività. È abbastanza facile da fare su sistemi basati su Unix tramite chiamate a fork / join, ma non così facilmente su sistemi Windows.

Il multi-threading è probabilmente l'approccio che la maggior parte della gente pensa quando parla di concorrenza. Non è difficile avviare più thread all'interno di un'applicazione, ma il diavolo si trova nei dettagli. È necessario coordinare la condivisione dei dati tra thread (di solito utilizzando blocchi) che possono portare a deadlock o dati in uno stato non valido. Devi anche capire come comunicare tra thread usando concetti come semafori, variabili condizionali ecc.

Il vantaggio di tutto questo è che, una volta compreso, puoi utilizzare in modo più efficace l'hardware sottostante. In questi giorni è praticamente la norma per un processore avere più core. Utilizzando la programmazione simultanea puoi far funzionare questi core per te e la tua applicazione otterrà un miglioramento della velocità.

Lo svantaggio è che devi iniziare a pensare a come dividere la tua applicazione in parti piccole che possono essere eseguite su thread diversi. Questo è molto più difficile di quanto sembri. Inoltre, le soluzioni altamente concorrenti possono essere scomode per il test unitario in quanto l'ordine di esecuzione è meno deterministico.

Al giorno d'oggi la maggior parte delle lingue viene spedita con un'astrazione sulla maggior parte dei primitivi simultanei per semplificare la vita. Ad esempio, .NET 4 viene fornito con la Libreria parallela attività che semplifica la vita. In Java land hanno il pacchetto Concurrency .

Recentemente ho avuto un compito molto interessante da svolgere in cui il multiprocessing mi ha salvato. Fondamentalmente dovevo fare molte richieste a pochi server separati, occupandomi di piccole quantità di dati, ma di molte richieste.

Lavorando con PHP, ho fatto le cose alla vecchia maniera e il miglior tempo che ho ottenuto dopo alcune ore di lavoro ha portato ~ 120 secondi per eseguire un determinato test (molte richieste + ritardo della rete + no asincrono)

Ma non era abbastanza vicino a quello di cui avevo bisogno, e dopo aver fallito miseramente con il multiprocessing di PHP, sono passato a Python.

Dopo alcune ore, ho avuto uno script di multiprocessing Python in esecuzione in 20 secondi, e dopo un po 'di manipolazione con i timeout e no. dei thread da utilizzare, l'ho ridotto a ~ 10 secondi .

Questo era per un sito web scritto al 100% in PHP, ad eccezione di un singolo script Python a 100 righe. E il tutto funziona perfettamente.

La mia conclusione sarebbe che anche se non ti aiuta giorno per giorno, potresti incontrare situazioni in cui conoscere almeno le basi della programmazione concorrente ti aiuterà molto.

Buona fortuna e buon codice!

PS: Non sto cercando di bash PHP, ma PHP semplicemente non era lo strumento giusto per il lavoro a portata di mano.

PS2: Conoscere una nuova tecnologia o un nuovo modo di fare le cose può aprire la porta a un nuovo mondo di possibilità.

Se fai qualsiasi tipo di sviluppo web, entra in gioco la concorrenza, almeno con la maggior parte delle lingue. Ad esempio, io uso molla per lo sviluppo web e ogni nuova richiesta arriva come filo proprio. Pertanto, se qualsiasi richiesta finisce per accedere a un oggetto condiviso, in cui lo stato può essere modificato di una variabile, la concorrenza è un fattore molto importante e deve essere presa in considerazione. Se non è così, i dati possono essere modificati in modi imprevedibili e può causare il danneggiamento dei dati. Non è fondamentale conoscere ogni minimo dettaglio sulla concorrenza ma imparare pezzi alla volta è importante per capire meglio la programmazione delle app Web, se si sta lavorando su app desktop, forse non è così importante a meno che non sia necessario eseguire più thread

Scopri le informazioni sui sistemi operativi. La lettura del codice sorgente di scheduler e driver di dispositivo aiuterà; sono decisamente concomitanti.