Dans l'exemple que tu donnes, il faudrait mieux monter un verrou (ou un sémaphore) pour protéger running.
Le but de mon exemple était de montrer de manière simple comment
le comportement optimisant d'un compilateur peut être pénalisant
lorsqu'une variable est modifiée de manière extérieure.
Le but n'était pas de faire une démonstration de programmation
multi-thread super bien ficelée (encore que, je ne vois pas trop ce
qu'on peut reprocher à cet exemple, et en quoi un verrou réglerait
le problème).
Cela dit, tu as tout à fait raison de signaler que "volatile" est très
utile pour gérer le matériel.
En cherchant rapidement sur google, j'ai trouvé ceci:
Cela résume assez bien les différents cas que l'on peut rencontrer
(programmation multithread, traitement d'interruptions, devices
utilisant du "memory-mapped I/O", ...)
[^] # Re: explication sommaire
Posté par galactikboulay . En réponse au message petite question..... Évalué à 3.
Le but de mon exemple était de montrer de manière simple comment
le comportement optimisant d'un compilateur peut être pénalisant
lorsqu'une variable est modifiée de manière extérieure.
Le but n'était pas de faire une démonstration de programmation
multi-thread super bien ficelée (encore que, je ne vois pas trop ce
qu'on peut reprocher à cet exemple, et en quoi un verrou réglerait
le problème).
Cela dit, tu as tout à fait raison de signaler que "volatile" est très
utile pour gérer le matériel.
En cherchant rapidement sur google, j'ai trouvé ceci:
http://www.programmersheaven.com/articles/pathak/article1.htm(...)
Cela résume assez bien les différents cas que l'on peut rencontrer
(programmation multithread, traitement d'interruptions, devices
utilisant du "memory-mapped I/O", ...)