clros ha scritto:Vedi sopra: non avendo una visione generale (o particolaregiata) del tutto, anche io credevo che in effetti usare i thread di java o altro fosse conveniente (e in Java, almenochè non si vogliono fare cose particolari, è anche facilissimo farlo).
Tutt'altro: in Java usare i thread è assurdamente complesso. In primo luogo il brillante concetto di 'monitor' (e le synchronized) è fonte di inefficienze *paurose*. Ma questo, possiamo dire, che chissene frega. Non fosse che da un falso senso di sicurezza e fa perdere di vista il problema di proteggere la sezione critica proteggendo tutto un metodo.
In secondo luogo questo senso di sicurezza porta direttamente all'idea (falsa, come si mostrerà poi) che lavorare con i thread sia semplice. E si scrivono programmi inutilmente inefficienti[0], usando un modello a memoria condivisa che è poco adatto a risolvere i problemi.
Tra l'altro anche a livello di API, ho dato per 'sbaglio' un occhiata alle API di Ruby, e ho visto che sono *grandemente* più semplici da usare. Poi i Thread di Ruby (al momento) sono solo dei green thread, ma questo è un discorso a parte.
Questo è quello che scrivono Van Roy e Haridi nel loro bellissimo libro:
Concurrency in Java is complex to use and expensive in computational resources. Because of these difficulties, Java-taught programmers conclude that concurrency is a fundamentally complex and expensive concept.
Program specifications are designed around the difficulties, often in a contorted way. Biut these difficulties are not fundamental at all. There are forms of concurrency that are quite useful and yet as easy to program as sequential programs (e.g., stream programming as exemplified by Unix pipes).
Furthermore, it is possible to implement threads, the basic unit of concurrency, almost as cheaply as procedure calls. If the programmer were taught about concurrency in the correct way, then he or she would be able to specify for and program in system without concurrency restrictions (including improved versions of Java).
Concepts, Techniques and Models of Computer Programming,
Peter Van Roy and Seif Haridi
Aggiungo: gli autori danno per scontato che i programmatori si accorgano che usare i thread è complesso. Purtroppo sbagliano: i programmatori non se ne accorgono fino a quando non si scontrano in un problema di media complessità e ci restano dentro.
----
[0] inefficienti al di la dei meccanismi di caching: i vari metodi non è infrequente che loggino roba o magari addirittura scrivono su db e/o rete. Ecco, mettere un lock che dura per tutto l'I/O è a dir poco criminale.
, pero' moooolto interessante!
, per carita', e' indubbiamente un'autorita' nel suo campo, ma non apprezzo come scrive...
infatti...