[Kos-dev] Nouvelles kwaitqueue

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> lock, mais ce n'est pas les fonctions qui manipulent les
    Thomas> kwaitqueues qui s'occupent de ce lock.

Oui. C'est pour ca que je prevois de rajouter 2 macros :
 #define kwq_lock(wq,flags) exclusive_spin_lock(wq.lock, flags)
 #define kwq_unlock(wq,flags) ...

    Thomas> Par exemple, si on a une sémaphore, on aura
    Thomas> vraisemblablement au minimum :

    Thomas> struct sem { kwaitqueue_t kwq; spinlock_t lock; };

Non, c'etait pas l'idee. L'idee c'est que le lock soit integre dans la
wq, mais soit gere par le mecanisme de synchro au-dessus (scheduler,
sem, mutex). Et que les fonctions _add/_retrieve/_is_empty soient
UNSAFE (comme dit en commentaire dans le .h). Et c'est pour ca aussi
qu'il y'a des appels a exclusive_spin_check_locked(kwq->lock) dans
_add/_retrieve, pour verifier que le thread possede bien un
lock. Bref, le lock dans kwq n'est pas franchement necessaire a cet
endroit (il pourrait tres bien se situer dans scheduler/sem/mutex
seulement), mais il permet quand meme de faire des verif comme quoi le
thread courant possede bien un lock pdt l'appel a
_add/_retrieve. C'est tout.

Niveau utilisation, par exemple, pour sem, on a bien

struct sem { int value; kwaitqueue_t wq; };

Puis sem_down :
  kwaitqueue_lock(sem->wq, flags)
  sem->value--;
  if (...)
    { kwaitqueue_add(sem->wq, myself); }
  ...
  next_thread = scheduler_get_ready();
  cpl0_switch(myself, next_thread, sem->wq.lock)
  ...

Sachant que a son tour scheduler_get_ready(the_thread) :
  kwaitqueue_lock(cpu_wq, flags);
  kwaitqueue_retrieve(cpu_wq, NULL, NULL, & next_thread);
  set_current_thread(next_thread);
  kwaitqueue_unlock(cpu_wq, flags);
  return next_thread;

    Thomas> Bref, je me demande si kwaitqueue ne devrait pas etre
    Thomas> completement unsafe, 

C'est le cas actuellement.

Ceci dit, la ou on peut nuancer, c'est dire : il y'a pas 1 lock par
wq, mais 1 lock pour toutes les wq. Le truc, c'est qu'alors il faut
gerer correctement la reetrance des locks (genre sem_down qui lock
puis qui appelle reschedule_get_ready() qui appelle a nouveau lock sur
le meme spinlock).

Bonne journee,

-- 
d2