[Kos-dev] ca impliquerait koa ?

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@utbm.fr> writes:
    Thomas> dois-je recopier tous les threads d'une
    Thomas> team lors du fork(), a mon avis, la reponse est oui, mais
    Thomas> qu'en penses-tu ? 

A mon avis : oui tout pareil. On peut commencer par partir sur cette
voie la ("on the fly"). Mais...

Visiblement, la semantique Posix dit que seul le thread qui appelle
fork() doit subsister dans le processus fils. Je comprends pas trop
les raisons profondes, mais elles doivent exister. Par consequent,
chez Posix, ils sont obliges de rajouter la primitive
pthread_at_fork() pour que les synchros soient correctement gerees
au fork(), histoire d'eviter les deadlocks. Peut-etre une espece
d'explication : ils veulent eviter que des threads soient dupliques
sans en etre avertis (ceux qui ne font pas le fork).

    Thomas> * une team A a un thread A et un thread
    Thomas> B. Le thread A est bloque en attente dans une wait
    Thomas> queue. Le thread B fait un fork(). Si la reponse a la
    Thomas> question 1 est positive, alors je dois recopier et le
    Thomas> thread A et le thread B dans la nouvelle team B. Mai sle
    Thomas> thread A de la nouvelle team B doit lui aussi etre bloque
    Thomas> en attente dans la waitqueue ?

Je propose une vision "babel" des choses : une synchro de type
waitqueue est une SR.

Si c'est une synchro "logique" (ie genre un mutex/semaphore/..., ie
pas un disque ni matos physique) *propre a la team* (ie "intra-team"
dans la suite), alors j'imagine plutot que le fork() doit
s'accompagner de la recopie de la SR de la synchro (en plus de la
creation de nvelles ressources), et donc on se retrouve avec 2
waitqueues : celle de la team A avec les threads de la team A, et
celle de la team B, avec les threads equivalents de B.

Ca souleve 2 choses :
  - une synchro est une SR, et chaque team qui se synchronise dessus
    le fait via sa propre ressource qui pointe dessus (comme d'hab
    avec babel).
  - il faut distinguer les synchro intra-team des synchro
    inter-team. Pour les intra-team => recopie de la SR de la synchro
    au moment du fork. C'est le cas des synchro genre
    mutex/semaphore/condition/mqueue des pthreads. Pour les inter-team
    => faire comme tu dis (rajouter les nouveaux threads dans la liste
    de synchro, qui elle reste globale a tout le systeme). C'est ce
    qui se passe si la ressource en question est un fichier et que les
    threads font un select() dessus => la SR fichier est bien la meme
    pour tous les threads de toutes les teams.
  - au moment du fork(), il faut etre capable de recuperer toutes les
    SR intra-team sur lesquelles chacun des threads est en
    attente. Et lors de la duplication de chaque thread, il faut
    rajouter le nouveau thread sur la liste d'attente de la nouvelle
    SR intra-team nouvellement recopiee de l'ancienne.

Pour ce qui est du 3eme point : si les synchros sont bien integres
dans Babel, alors on sait faire.

A noter qu'avec la notion de synchro inter et intra-team, on a a faire
a des types de ressources qui ne sont pas du type read/write (ie
fichier ou caractere) classiques, mais 1/ qui ne sont pas mappables
(quoique...), 2/ qui ont des methodes plus reduites (et les methodes
style lock/unlock [mutex], up/down [semaphore], wait/signal/broadcast
[condition]...).

On pourrait en profiter pour rajouter les choses suivantes au sein
d'une SR :
  - un type de SR : intra ou inter-team => pour l'intra-team, il y a
    creation et recopie d'une nouvelle SR a chaque fork(). On pourrait
    imaginer que ce champ soit modifiable en run-time.
  - une methode duplicate() associee a une SR intra-team uniquement :
    appelee apres que la SR ait ete allouee suite au fork, et que les
    ressources de la nouvelle team aient ete crees + avec mise a jour
    pointeur SR vers la nouvelle SR. Ca permettrait par exemple de
    modifier certains champs dans la nouvelle SR de synchro, et qui
    dependent du type de synchro, du style : la liste des threads qui
    possedent le semaphore...

Voila le fork() tel que je le vois pour l'instant :
  - recopie AS/PD/PT moyennant droits r/w pour les histoires de COW
    avec les MAP_PRIVATE (cf mail d'avant)
  - allocation/recopie ressources
  - allocation/recopie SR de type intra-team + mise a jour des
    references ressource -> SR intra-team nouvellement crees + appel
    methode duplicate(new_sr, old_sr) de chaque SR intra-team
    nouvellement creee.

On pourrait par la suite remarquer l'analogie SR intra-team/inter-team
avec les MAP_PRIVATE/SHARED de la VM, et en profiter pour renommer
intra-team en "SR private", et inter-team en "SR shared".

    Thomas> * autre probleme, plus bas niveau. Je suis dans une team A,
    Thomas> avec un thread A et un thread B. Le thread A demande un
    Thomas> fork() -> creation de la team B. Dans le thread A de la
    Thomas> team A je dois donc retourner le PID du fils (de la team
    Thomas> fille donc), ca c'est facile. Mais l'execution du thread A
    Thomas> de la team B doit se poursuivre en CPL3, en retournant 0 !
    Thomas> Comment je peux faire ca ?

Charger le registre eax a 0 lors de la confection du nouveau
contexte d'exec pour le thread de B, tu crois que ca suffit pas ?

Bonne journee,

-- 
d2