vendredi 24 janvier 2014

Thread

Les tutos java font beaucoupe de l'idée que l'interface utilisateur doive

se définir à partir du EDT, event dispatch thread. De fait, depuis 1990+, la

complexité des ordis a pour conséquence que différentes séquences d'exécutions -

voir threads - sont actifs en même temps. Le potentiel pour incohérence et

interblocage(deadlock) se dessine.

Une petite appli java n'est pas a priori thread safe. Oracle, IBM, Microsoft offrent

tous des systems qui le sont, payants, à partir de différentes notions . Le domaine est large,

et d'intérêt au niveau software engineer. Grosso, une appli java qui suit les consignes

sera protégée par le biais de la sérialization, qui interdit, par exemple, un paint et un

repaint en même temps. Car les interfaces java actuelles se construisent sur une

fenêtre heavyweight (awt) et un panel lightweight( swing). Divers opérations repaint

sur différents components vont aussi se résoudre en une seule action.

Le AWT, Abstract Tool Kit, fait appel à l"abstraction. En exemple, un petit commerce

aura des employés mais la notion est abstraite. Dans les faits, il n'y a que des employés

permanents payés à la semaines, et des employés temporaires payés à l'heure. De

même, une classe abstraite n'aura pas d'implémentation directe, mais ses descendants

pourront se servir de ses méthodes. La création d'un delegate, classe qui entreprend

le travail d'une autre, serait une forme d'abstraction au service de la thread safety.

 


 

Aucun commentaire: