[Kos-dev] "Race condition" 1

d2 kos-dev@enix.org
26 May 2003 10:25:14 +0200


>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Il me semble clair qu'on a pas la garantie que
    Thomas> cpl0_switch_with_return s'éxécute en un seul bloc, sans
    Thomas> interruptions.

Si : ASSERT_FATAL(test_interrupt_enabled() == FALSE); dans
cpl0_switch_with_return. Donc quand un thread demande un switch, avant
le switch, IE est a 0, donc quand on retournera vers lui, dans tous
les cas IE est remis a 0 au moment du iret. Le seul cas qui deconnait,
c'est quand le iret ne restaurait pas un contexte de thread qui avait
appele cpl0_switch_with_return, ie quand le iret restaurait le
contexte d'un thread tout neuf, pour lequel IE vaut 1. Mettre IE a 0
pour les nouveaux threads fait que dans tous les cas le iret restaure
le contexte d'un thread avec interruptions desactivees. Il serait pas
inutile d'ailleurs de mettre un test du type ASSERT_FATAL sur le IE a
0 du eflags du to_context dans cpl0_switch_no_return_internal et
cpl0_switch_with_return .

    >> Pour les semaphores, faudrait reflechir en effet, pour le
    >> moment je pense que ce serait plus propre de passer un spinlock
    >> en parametre. Le probleme que je me pose c'est "est-ce qu'on
    >> risque pas", avec l'empilement de nos synchro les unes sur les
    >> les autres (kmsg / ksem / kwq), "d'avoir besoin de relacher
    >> *plusieurs* wq au moment du switch"...

    Thomas> "au moment du switch" ?

Oui, au moment ou on appelle kwaitqueue_add_....

    Thomas> En ce qui concerne le passage du spinlock en paramètre, il
    Thomas> faudra passer un pointeur, et donc toutes les macros
    Thomas> *_spin_* ne fonctionneront pas.

?

Bonne journee,

-- 
d2