Toujours aussi peu d'entrée... En fait, en ce moment, je n'ai plus vraiment le temps.

Déjà, je fréquente quelqu'un, et la relation semble partir sur des bases sérieuses, ce qui fait que je suis moins souvent chez moi que d'habitude.

Ensuite, je suis en train de dévelloper la 4ème version de mon simulateur d'ascenseurs. Ya des vagues comme ça... Le point positif, c'est que cette fois-ci, ça semble tourner sans problème (ça rame pas, ça anime plusieurs machines en même temps, bref, ça fonctionne comme un "vrai programme")

Enfin, j'ai eu hier une petite discussion pour savoir si la technique du multi-threading était quelque chose d'efficace. Pour ma part, je pense que c'est approprié dans certains cas (serveurs d'applications). Dans d'autres, comme par exemple des interfaces graphiques (Swing, Qt, MFC), cela ne se justifiait pas : outre la lourdeur que cela apportait en terme de réactivité, ça complexifie la lecture du programme. En effet les programmes multi-threadés sont plus complexes du fait qu'ils doivent gérer des séquences d'exécutions qui sont en général imprédictibles (du fait de la nature de l'ordonnanceur du système d'exploitation). Ça oblige à utiliser des objets comme des sémaphores ou des mutex qui généralement entrainent des interblocages pénibles à résoudre.

La communication entre thread aussi est pénible : passer par une zone de mémoire partagée n'est pas forcément triviale puisqu'il faut mettre en place des systèmes de synchronisation qui, au final, font la même choses que des tubes. On m'a parlé d'arguments de "modernité" (c'est plus moderne de faire des threads, etc). Hmmm, je ne suis pas particulièrement convaincu. La complexification d'un système n'est pas vraiment signe de modernité, surtout quand il faut repasser par derrière et comprendre comment ça fonctionne. Enfin, lorsque l'on voit les divers implémentations des threads, et de toutes les bidouilles auxquelles il faut recourir pour faire fonctionner les choses correctement, je ne suis pas persuadé qu'on ai beaucoup avancé.