[Multithreading] Green Thread vs System Thread

[cisc]

Considerando che il ormai il pc più scarso in vendita monta un multicore, vorrei fare il punto della situazione sugli strumenti e le soluzione che i linguaggi a più alto livello offrono per supportare la programmazione multithreading, e quindi anche fino a che punto sfruttano le architetture multicore moderne.

Ecco in sintesi quello che so io riguardo ad alcuni linguaggi:
Java: System Thread
Python (CPython): System Thread con GIL (Global Interpreter Lock)
Stackless Python: Green Thread
Ruby: System Thread con GIL
Erlang: green processes

Cosa ne pensate di queste soluzioni? Quale vi sembra la soluzione più adeguata?

[cdimauro]

Non ti saprei dire perché per adesso non c'ho sbattuto la testa (ma fra qualche tempo capiterà sicuramente, perché in azienda abbiamo in programma di sfruttare anche il multiprocessing anziché lanciare n applicazioni, una per ogni core).

Per Python posso dirti che nelle versioni 2.6 e 3.0, che saranno rilasciate il 1 ottobre (se non ci saranno slittamenti, ma al massimo si tratterebbe di pochi giochi perché lo sviluppo è a buon punto), sarà incluso nella libreria standard un modulo chiamato multiprocessing che ricalcherà quasi esattamente il modulo threading, ma permetterà di gestire in maniera semplice i processi e, quindi, di sfruttare tutti i core del sistema (posto che gli algoritmi siano parallelizzabili, ovviamente).

A parte questo, c'è un altro modulo che finora ha riscosso un buon successo e si chiama Parallel Python che, a differenza del precedente, ha un approccio più "funzionale" alla parallelizzazione degli algoritmi, ma finora non ho avuto modo di metterci le mani (e comunque, arrivando multiprocessing nella libreria standard, perderà interesse).

[cisc]

Ma in applicazioni in cui sono importanti le prestazioni e c'è molta "comunicazione" tra i vari thread passare al multiprocessing non è il massimo

[cdimauro]

Non si può avere tutto: se servono le prestazioni, bisogna sfruttare tutti i core della CPU. Però se i processi comunicano troppo, come dici tu, le prestazioni calano.

O l'uno o l'altro: non c'è scelta, se l'algoritmo non può essere scritto per sfruttare i processi limitando al massimo lo scambio di informazioni.

Finora ho avuto la fortuna di realizzare server "autonomi", quindi ho lanciato n processi, uno per ogni core delle varie macchine, e il sistema load-balacing ha provveduto a smistare le varie richieste a questi n server.
Purtroppo non tutti i server possono essere realizzati così.

[cisc]

ma ci sono situazioni in cui non è possibile avere n server autonomi, o in cui anche limitando al massimo la comunicazione tra i processi, tale comunicazione crea ugualmente problemi nelle prestazioni, basterebbe avere system thread con meccanismi di sincronizzazione più raffinati di un GIL per migliorare la situazione secondo me. La chiave potrebbe essere un mapping M:N tra thread in VM e system thread. Dopotutto a mio avviso le architetture multicore sono studiate in modo particolare per favorire la programmazione multithreading.