Le astrazioni di concorrenza emulano i processi UNIX?

8

OK, stavo riflettendo su questo oggi, e sono venuto a chiedere pareri completamente soggettivi e di pregiudizi su di esso. Paradossalmente, nonostante ciò, non penso che sia anche foraggio da guerrafiamma. Penso che ci sia spazio per una conversazione perfettamente civile - Difficilmente Vim vs Emacs.

Ho usato molte astrazioni di concorrenza, in particolare quelle costruite in cima ai thread. C'è una grande tendenza tra di loro, sia che passi il messaggio, sia immutabile-per-predefinita, o thread-local-by-default o altri.

La tendenza è che stanno invertendo l'idea dei thread rendendo la condivisione dei dati esplicita piuttosto che implicita. Cioè, tutti i dati non sono condivisi se non diversamente specificato, che è l'opposto del threading tradizionale trovato in linguaggi come Java. (So che Java supporta le proprie astrazioni di concorrenza di livello superiore però.) Ad esempio, si passano esplicitamente messaggi. Si specifica esplicitamente quali variabili sono thread-local. Dichiarate esplicitamente quali variabili sono mutabili. Questi sono solo alcuni esempi trovati in alcune lingue.

Ho pensato che questo facile stile di concorrenza fosse un concetto moderno. Mi sono sbagliato. Ho iniziato a giocare con giocattoli UNIX come fork () e pipe () di recente, e sono rimasto scioccato nello scoprire che meccanismi di concorrenza facili ed espliciti esistevano sin dall'inizio di UNIX.

C'è qualcosa di strano nel rendersi conto che C + UNIX degli anni '70 rende la lontana molto più facile di molti moderni meccanismi di threading di tendenza.

Quindi, ecco cosa mi chiedo ... queste astrazioni di thread moderne stanno semplicemente cercando di emulare processi in stile UNIX in cima ai thread, con tutti i loro tratti espliciti e non condivisi per default? So che alcuni meccanismi come la STM offrono cose come le transazioni in stile DB che sono in realtà una soluzione moderna e innovativa per la concorrenza, ma la maggior parte sembrano solo nuovi modi di fare ciò che i codificatori UNIX stavano facendo da molto tempo.

Solo per dire, non sono un fan dei fan di UNIX, non con un minimo di immaginazione. Sono consapevole del fatto che i processi sono molto più lenti dei thread da inizializzare su molte piattaforme, ma sto parlando di questo da una base concettuale.

    
posta Louis 17.07.2011 - 17:45
fonte

2 risposte

1

Buona osservazione, c'è sicuramente una tendenza alla condivisione esplicita (attraverso linguaggi o convenzioni funzionali). Il commento sui processi è più lento mi adatterei un po ': sono più heavy-weight , il che significa che non sono più lenti nell'esecuzione in raw performance, ma ogni switch tra loro prende un molto più lungo del passaggio da un thread all'altro. Hai già riconosciuto che esistono altre forme di concorrenza e riconosci STM . Vorrei solo aggiungere che esiste (oltre alla condivisione esplicita e STM) anche una tendenza crescente verso pooling di thread (attività parallele, assegnare attività ai thread di lavoro che sono stati avviati in anticipo e riciclarli) : Sicuramente la strada da seguire per quanto riguarda le prestazioni e curiosamente un approccio diverso alla condivisione esplicita perché i thread raggruppati sono in genere tutti in un unico processo.

    
risposta data 17.07.2011 - 18:40
fonte
2

Penso che sia meno una questione di X emulare Y, piuttosto che cercare di trovare un equilibrio.

I processi completamente separati mantengono la vita relativamente semplice. Rendono abbastanza facile costruire cose come pipeline di processi che prendono almeno qualche vantaggio da più processori. Ci sono anche degli svantaggi piuttosto ovvi - in particolare la mancanza di flessibilità e un bel po 'di overhead.

Un singolo processo con più thread di condivisione dell'esecuzione sostanzialmente tutte le risorse inverte sostanzialmente quelli: overhead più bassi e molta flessibilità, a scapito di essere più difficili da progettare e / o mantenere stabili.

Per la maggior parte, ciò che sta accadendo è che le persone stanno lavorando per trovare una via di mezzo che fornisce quasi la flessibilità e la velocità dei thread, con il design più semplice e un risultato più stabile di processi separati (e, penso che siano in gran parte successo, almeno in parte).

    
risposta data 18.07.2011 - 00:45
fonte

Leggi altre domande sui tag