Il giorno 28/gen/08, alle ore 11:32, [EMAIL PROTECTED] ha scritto: > >> Al di la di quello che rende 'semplice' un popolare linguaggio di >> programmazioni progettato da qualche control freak, il problema è che >> il modo più naturale, logico e comodo di lavorare con i thread è un >> modello a messaggi/code e *senza* stato condiviso. > > Bho, fore ora andiamo anche OT, ma mi sento di dissentire quest'ultima > affermazione. Se non altro dopo tutti i vari "filosofi a cena" e > "barbieri" > fatti a laboratorio concorrente. I Thread lavorano su strutture dati > condivise. E in generale il dato condiviso fa parte dello stato del > programma... >
Strutture dati condivise che devono essere adeguatamente protette dall'accesso concorrente, se non vuoi i bug più bastardi che esistano. Tra l'altro, bug, deadlock e quant'altro, imprevedibili e che spesso *non* si presentano sul sistema di testing, ma solo quando il software va a regime, in produzione. Il multithreading a stato condiviso è troppo difficile da gestire, non ne vale sul serio la pena, soprattutto dal momento che il multiprocesso non è idealmente così distante, IMHO...diverso è se consideri l'approccio asincrono, lì va riconsiderata tutta l'architettura, e magari non è quello che ti serve per l'esame, ma io considererei bene di adottare un'architettura multiprocesso piuttosto che multithread a stato condiviso! -- Antonio Valente _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python