Quand au masquage des ITs pour protéger l'intégrité d'une variable, c'est en règle général vrai de la protéger mais tout dépend de ce que l'on fait...
- C'est vrai si l'on écrit sur cette donnée à partir d'un calcul qui utilise sa valeur courante.
- C'est un peu moins vrai si d'un côté on se contente d'écrire une valeur déterminée (0)
- Ca l'est encore moins quand on écrit sur la donnée d'un côté et que l'on se contente de la relire de l'autre (exemple des FIFOs non bloquante producteur/consommateur).
Il faut rappeler aussi que l'usage des mutex ou verrou bloquant est réservée interthread, et que l'IT devra utiliser les routines non bloquantes.
Attention aussi en masquant une IT, on peut désactiver plusieurs traitements qui ne sont pas concurrents, ou exposer une zone critique lorsque l'on réactive l'IT alors qu'il ne le faudrait pas (car le contexte appelant a désactivé l'IT).
# infos complémentaire sur l'accès concurrent aux variables
Posté par Selso (site web personnel) . En réponse au journal TapTempo sur STM32F469i-Discovery. Évalué à 0.
Quand au masquage des ITs pour protéger l'intégrité d'une variable, c'est en règle général vrai de la protéger mais tout dépend de ce que l'on fait...
- C'est vrai si l'on écrit sur cette donnée à partir d'un calcul qui utilise sa valeur courante.
- C'est un peu moins vrai si d'un côté on se contente d'écrire une valeur déterminée (0)
- Ca l'est encore moins quand on écrit sur la donnée d'un côté et que l'on se contente de la relire de l'autre (exemple des FIFOs non bloquante producteur/consommateur).
Il faut rappeler aussi que l'usage des mutex ou verrou bloquant est réservée interthread, et que l'IT devra utiliser les routines non bloquantes.
Attention aussi en masquant une IT, on peut désactiver plusieurs traitements qui ne sont pas concurrents, ou exposer une zone critique lorsque l'on réactive l'IT alors qu'il ne le faudrait pas (car le contexte appelant a désactivé l'IT).