2. Après un test and set réussi, le lock est pris !
Comme tu es très pointilleux sur les mots, je corrige le point "2."
2. Après un test and set réussi, la variable est modifiée ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
2. Après un test and set réussi, le lock est pris !
Comme tu es très pointilleux sur les mots, je corrige le point "2."
2. Après un test and set réussi, la variable est modifiée ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne