Perché non fili verdi?

Mentre so che le domande su questo sono già state trattate (ad es. Https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), non mi sento di avere una risposta soddisfacente .

La domanda è: perché JVM non supporta più i thread verdi?

Lo dice nelle FAQ Java in stile codice :

Un thread verde si riferisce a una modalità operativa per Java Virtual Machine (JVM) in cui tutto il codice viene eseguito in un singolo thread del sistema operativo.

E questo su java.sun.com :

Il rovescio della medaglia è che l'uso di thread verdi significa che i thread di sistema su Linux non vengono sfruttati e quindi la macchina virtuale Java non è scalabile quando vengono aggiunte CPU aggiuntive.

Mi sembra che la JVM possa avere un pool di processi di sistema pari al numero di core e quindi eseguire thread verdi su di esso. Ciò potrebbe offrire alcuni grandi vantaggi quando si dispone di un numero molto elevato di thread che si bloccano spesso (principalmente perché l'attuale numero di thread è limitato a JVM).

Pensieri?

Ricordo la JVM che abbandonava i thread verdi e si spostava sui thread nativi. Questo per due semplici motivi: i fili verdi erano francamente spazzatura e c'era la necessità di supportare processori multi-core con il limitato impegno degli sviluppatori disponibile su Sun.

È stato un peccato: i fili verdi forniscono un'astrazione molto migliore, consentendo alla concorrenza di essere uno strumento utile non un ostacolo. Ma i fili verdi non servono se non si possono superare diversi ostacoli:

• devono usare tutti i core della CPU a loro disposizione

• il cambio di contesto deve essere economico

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

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

• bravo a usare tutti i core della CPU

• bravo ad essere veramente concorrente, fornendo I / O indipendente ecc

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

• orribilmente avido di memoria, limitandone quindi il massimo numero utilizzabile

• una scarsa astrazione per qualsiasi base per esprimere il mondo reale, che è altamente concorrenziale ovviamente.

Al giorno d'oggi, un sacco di tempo del programmatore ora passa alla codifica di I / O non bloccanti, futures ecc. È un vero peccato non avere un migliore livello di astrazione.

Per fare un confronto, oltre a Erlang la nuova lingua Go fa un buon lavoro di enorme concorrenza. Il nonno di loro 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 fili falsi si bloccano su qualsiasi errore di pagina.

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

Tuttavia, sono d'accordo sul fatto che esistano alcune applicazioni (non Java) in cui un pool di processi che è possibile utilizzare come un pool di thread (ma con maggiore isolamento) sarebbe un'ottima cosa da avere. Le discussioni condividono praticamente tutto. Con i processi, puoi scegliere in modo specifico cosa condividere. Per quanto ne sappia, nessuno ha ancora tentato di implementarlo.

Non ci sarà alcun vantaggio per un codice Java medio. Java non è Erlang e i programmatori Java non hanno la stessa mentalità dei programmatori Erlang. La lingua non è mai stata pensata per essere utilizzata in questo modo.

Se vuoi il vero processo leggero - usa Erlang e crea migliaia di thread che comunicano tramite messaggi. In Java avrai una dozzina di thread che condividono una memoria comune con mutex e semafori. È solo un diverso modello di programmazione, progettato per una diversa serie di problemi.