Comment fonctionne linux Synchronize preempt nombre

Question

http://lxr.linux.no/linux+v2.6.35/include/linux/preempt.h#L21

Je viens d'essayer obtenir la source de Linux. J'ai vu ce compte anticipé et comment linux assure-t-il que le compte préemptif est atomique? Le code incrémente juste la valeur.

J'ai aussi une autre question. pourquoi les handles d'interruption doivent-ils maintenir une exclusion mutuelle? Parce qu'un seul peut exécuter à la fois non?

De même, lorsque les interruptions sont désactivées, que fait le système d'exploitation? Ignorer les interruptions ou maintenir une file d'attente?

Answer 1

Il incrémente preempt_count() - remarquez la () - qui est une macro est définie comme:

#define preempt_count() (current_thread_info()->preempt_count) 

Il incrémente une variable par thread, ce qui ne nécessite pas de verrouillage et est en sécurité.

---

Il est préférable de poser vos multiples questions comme des questions distinctes, mais brièvement:

• Les gestionnaires d'interruptions peuvent en général être interrompus par d'autres gestionnaires d'interruption;
• Les gestionnaires d'interruption peuvent s'exécuter sur un cœur de processeur tandis que le code d'un autre noyau s'exécute sur un autre noyau;
• Les interruptions sont généralement désactivées à l'aide d'un mécanisme matériel. Ceux-ci ont tendance à se rappeler des interruptions en attente, mais seulement jusqu'à un maximum par vecteur d'interruption.

Answer 2

Chaque processeur moderne a une variante de l'instruction atomique test-and-set.

Answer 3

L'opération sur la variable preempt_count n'est pas atomique. La région de code entre un inc et un dec d'un preempt_count d'un thread est garantie de ne pas être désactivée par le planificateur. Le changement de contexte à partir du thread actuel dans cette région de code ne peut se produire que dans d'autres exceptions ou interruptions intégrées. Après la fin de la première opération inc, les autres gestionnaires verront que la variable est non nulle et ne provoqueront donc pas de changement de contexte. Avant que l'inc ne se termine, le thread peut être éteint, mais ce n'est pas grave car le code n'a pas atteint la zone protégée.

Quelques détails: La définition d'une variable atomique devrait être quelque chose comme "Atomic variables are the ones on whom the read modify write operation is done as one instruction with out any interruption". L'opération "Read-Modify-Write" sur un preempt_count peut être interrompue par un autre gestionnaire d'exception ou un gestionnaire d'interruption mais uniquement de manière strictement intégrée, c'est-à-dire par la conception du noyau. Puisque ces opérations intégrées sont par paires, la valeur d'un preempt_count ne sera pas corrompue à la fin. Bien qu'une opération R-M-W puisse être interrompue et que le thread en cours puisse être désactivé (uniquement si aucune des multiples incorporées inc n'est terminée), cela est correct car le code n'a pas atteint la zone protégée. Une fois que le fil est remis en marche, il continuera à terminer l'opération R-M-W et, à partir de ce point, le fil en cours ne sera pas éteint tant que toutes les décomptes appariées ne seront pas toutes terminées.