(luKa)

Concludo la terna con degli esempi di varie forme di inteligenza collettiva: political parties, military units, trade unions, and corporations:

__Queste 3 nuvole le trovo molto evocative

Coordinazione ... immagino una figura di nuoto sincronizzato
     Cooperazione ... immagino una touche del rugby, i piloni alzano il saltatore durante una touche
           Cognition~Conoscenza ... immagino le conquiste appena consolidate e la nascita di nuove idee per il futuro durante una retrospective

Fonte: http://en.wikipedia.org/wiki/Collective_intelligence 

Tags :  Team Work | Complessità | Team | Conflitto | Negoziazione | Creatività | Team building |

 L a progettazione comincia con la scelta di un modello di programmazione della applicazione multi-threading da queste 2 cose:

• In che modo il disegno renderà riconoscibili gli oggetti che vengono eseguiti su/attraversati da più thread e avranno bisogno di una gestione della concorrenza?
  
  Una nota tecnica utile, la gestione della concorrenza serve quando thread diversi scrivono sullo stesso  field della classe oppure uno ci scrive e un altro ci legge. Queste sono chiamate le condizioni di Bernstein [1]
  
  
  
• Quale politica di gestione dello stallo verrà seguita e come il disegno la renderà evidente e aiuterà ad applicarla in modo consistente in tutta la applicazione ?
  
  La condizione di stallo è quando un thread per proseguire la sua elaborazione ha bisogno di allocare (mettere un lock) a un field di classe che però già allocato a sua volta da un secondo thread ... che è fermo ad aspettare un'altra risorsa allocata dal primo. [2]
  
  Si sceglierà una tecnica di prevenzione del deadlock (ad esempio allocando contemporaneamente tutti i lock necessari a una elaborazione oppure acquisendo lock sempre seguendo uno stesso ordine) o una tecnica di riconoscimento del deadlock in corso e limpiego di provvedimenti per uscirne (tipo il rollback di uno dei thread in deadlock).
  
  Oppure nel caoso specifico sarà possibile adottare  una strutturazione degli oggetti tali da evitare del tutto necessità di wait/lock e quindi lo stesso deadlock [3]

 
[1] A.J. Bernstein, "Program Analysis for Parallel Processing" IEEE Trans. on Electronic Computers, EC-15, October 1966
[2] Richard C. Holt: Some Deadlock Properties of Computer Systems. ACM Comput. Surv. Vol.4 Num.3, Sett 1972
[3]  Maurice Herlihy, "Wait-free synchronization" ACM TOPLAS Vol.13 Num.1, Genn 1991

Tags :  Progettazione Software |

Una citazione di Alan Turing del 1950

L'opinione popolare che gli scienziati procedano inesorabilmente da un fatto ben stabilito a un altro fatto ben stabilito, senza che intervenga mai l'influenza di una congettura non ancora provata, è del tutto errata.

Purché venga chiaramente messo in evidenza quali sono i fatti provati e quali siano le congetture, non può risultare alcun danno.

Le congetture sono di importanza fondamentale , dato che suggeriscono utili linee di ricerca.

»

L'obiettivo di progettare una applicazione multi-threading - oltre a garantire che funzioni correttamente - è di scriverla in modo comprensibile e che aiuta a modificarla e evolverla con tempi e sforzi sostenibili. 

Facendo manutenzione e evolvendo l'applicazione mi troverò ad esempio a cercare risposta a domande come queste, e vorrò riuscire a farlo senza bisogno di sacrifici eroici :

• Sto aggiungendo una nuova classe all'applicazione, quanti thread avranno accesso contemporaneo all'istanza della classe?
  
  
• Sto modificando il metodo di una classe per aggiungergli chiamate a metodi di altre classi, dovrò aggiungere dei lock ? quali e dove ?
  
  
• Ho necessità di distribuire  in 4 thread il carico lavoro che la applicazione ora sostiene su 2 thread , come devo sincronizzazione i 2 nuovi thread ?

E' singolare che le applicazioni multi-utente che accedono a un data-base sono molto più semplici da scrivere/modificare/evolvere delle applicazioni multi-threading anche se hanno molte similitudini e molte cose in comune.

I Db relazionali definiscono un modello di programmazione e gestione della concorrenza che bisogna adottare. Nelle applicazione multi-threading  senza questi vincoli uno stesso problema può essere affrontato in una varietà di modi differenti e cosi la ricerca di una soluzione semplice all'inizio è più impegnativa .  Viceversa una volta acquisito un repertorio di soluzioni efficaci l'unico limite per migliorarle, adattarle e reinventarle è la fantasia.

Update 18-5-2008 sintesi di info e riferimenti utili dai comments

Flynn's Taxonomy
- http://en.wikipedia.org/wiki/Flynn_taxonomy
- http://mugur.roz.md/computer-science/computer-science/images/fig09_02_0.jpg

Monads
- http://blogs.ugidotnet.org/dmantovani/archive/2007/11/26/89935.aspx
- http://channel9.msdn.com/ShowPost.aspx?PostID=358968

 Parallel C#
- http://blogs.ugidotnet.org/dmantovani/archive/2008/05/13/92658.aspx

Microsoft Robotics Studio:
- http://msdn.microsoft.com/en-us/robotics/default.aspx
- http://channel9.msdn.com/ShowPost.aspx?PostID=206574

Questi post sul multi-threading sono limitati a linguaggi Object Oriented su hw con architetture classica Von Neumann (cioè architetture control-flow = istruction-flow di tipo SISD e non Multipme Instruction stream Multiple Data strueam e nemmeno a arcitettura  data-flow; vedi la tassonomia di Flynn). Cioè a .NET C# su PC e Server comuni .