Perché non i fili verdi?

Ricordo che JVM abbandonava i thread verdi e si spostava ai thread nativi. Questo era dovuto a due semplici motivi: i thread verdi erano francamente noiosi e c'era bisogno di supportare i processori multi-core con il limitato sforzo di sviluppo disponibile su Sun.

Questo è stato un peccato: i fili verdi forniscono un'astrazione di gran lunga migliore, consentendo alla concorrenza di essere uno strumento utile e non un ostacolo. Ma i fili verdi sono inutili se non è possibile superare diversi ostacoli:

• devono utilizzare tutti i core della CPU disponibili per loro

• il cambio di contesto deve essere economico

• I / O può bloccare qualsiasi thread impegnato in esso, ma non nessun altro thread e certamente non tutti gli altri thread, come in alcune implementazioni precedenti.

Mi sono spesso chiesto perché il multi-threading sia così difficile in Java, ma ora sta diventando più chiaro - in definitiva ha a che fare con il passaggio ai thread nativi, che sono:

• bravo a usare tutti i core della CPU

• bravi a essere realmente concomitanti, fornendo I / O indipendenti ecc.

• lento al cambio di contesto (rispetto alle migliori implementazioni di thread verdi)

• orribilmente goloso con la memoria, quindi limitando il numero massimo utilizzabile di essi

• una povera astrazione per qualsiasi motivo per esprimere il mondo reale, che è ovviamente molto concorrente.

Al giorno d'oggi, un lotto di programmatore ora inizia a codificare I / O non bloccanti, i futuri, ecc. È un grosso peccato che non abbiamo un migliore livello di astrazione.

Per fare un confronto, oltre a Erlang il nuovo linguaggio Go fa un buon lavoro di enorme concorrenza. Il nonno di tutti rimane Occam , ancora un progetto di ricerca in corso.

Un singolo processo che simula più thread ha molti problemi. Uno di questi è che tutti i thread contraffatti si bloccano su qualsiasi errore di pagina.

L'alternativa che suggerisci, un insieme di processi, presenta alcuni vantaggi e alcuni svantaggi. Il più grande vantaggio, l'isolamento dei "thread", non ti farebbe molto guadagnare qui. Il grande svantaggio, l'estrema difficoltà di implementazione e la sincronizzazione meno efficiente, è il killer di affare qui.

Tuttavia, sono d'accordo sul fatto che esistano alcune applicazioni (non Java) in cui un pool di processi che potresti usare come un pool di thread (ma con più isolamento) sarebbe una grande cosa da avere. I thread condividono praticamente tutto. Con i processi, puoi scegliere specificamente cosa condividere. Per quanto ne so, nessuno è andato allo sforzo di implementarlo ancora.

Non ci sarà alcun vantaggio per un codice Java medio. Java non è Erlang, e i programmatori Java non sono nella stessa mentalità dei programmatori di Erlang. Il linguaggio non è mai stato concepito per essere usato in questo modo.

Se vuoi i veri processori leggeri - usa Erlang e crea migliaia di thread comunicanti tramite messaggi. In Java avrai una dozzina di thread che condividono una memoria comune con mutex e semafori. È solo un modello di programmazione diverso, progettato per un diverso insieme di problemi.