Peut-on avoir une indication pour éclairer notre lanterne ?
Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
En théorie ils ne peuvent pas, en pratique c'est pas grave.
Méthode du gros rouge qui tache.
le thread t1 veut une variable privée A
il pose un write-lock dessus
il pose une variable de condition signal sur la présence write-lock
Au cas ou il recoit un signal sur cette condition, ils ait qu'un autre thread a enlevé le write-lock pour aller écrire dans la variable. De rage il termine le processus.
Méthode plus subtile, mais à peine :
Le scheduler a une variable en readlock qui contient le dernier thread appelé
le thread veut une variable privée B
il créé deux variables B1 et B2
il write-lock les deux variables
il les mets à la même valeur
il pose 3 variables de condition signal : 2 sur la présence de chacun des writelock et un sur l'égalité de B1 et B2
Au cas ou il recoit un signal sur une des trois conditions
a) detach du dernier thread appelé
b) constatation des dégats : peut-on dire qu'une des copies est fiables ? (généralement : oui)
c) réparation des dégats : on reduplique la copie fiable et on remet les locks.Si la réparation est impossible exit.
Le gros problème c'est que c'ets lourd, lent et qu'il y a des pièges de synchros et des conditions de courses dans tous les sens. Je laisserais pas çà dans un code en prod, mais pour le débug ca marche pas mal du tout. En y passant du temps il doit être possible de faire une implémentation "propre" sur la même idée (ie un truc dans lequel on est sur à 100% qu'un thread n'a pas pu enlever les deux write-lock, changer les valeurs des deux variables et remettre les deux write-lock à l'identique sans que les variables de conditions n'aient le temps d'être mise à jour.)
[^] # Re: séparation des privilèges
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
En théorie ils ne peuvent pas, en pratique c'est pas grave.
Méthode du gros rouge qui tache.
le thread t1 veut une variable privée A
il pose un write-lock dessus
il pose une variable de condition signal sur la présence write-lock
Au cas ou il recoit un signal sur cette condition, ils ait qu'un autre thread a enlevé le write-lock pour aller écrire dans la variable. De rage il termine le processus.
Méthode plus subtile, mais à peine :
Le scheduler a une variable en readlock qui contient le dernier thread appelé
le thread veut une variable privée B
il créé deux variables B1 et B2
il write-lock les deux variables
il les mets à la même valeur
il pose 3 variables de condition signal : 2 sur la présence de chacun des writelock et un sur l'égalité de B1 et B2
Au cas ou il recoit un signal sur une des trois conditions
a) detach du dernier thread appelé
b) constatation des dégats : peut-on dire qu'une des copies est fiables ? (généralement : oui)
c) réparation des dégats : on reduplique la copie fiable et on remet les locks.Si la réparation est impossible exit.
Le gros problème c'est que c'ets lourd, lent et qu'il y a des pièges de synchros et des conditions de courses dans tous les sens. Je laisserais pas çà dans un code en prod, mais pour le débug ca marche pas mal du tout. En y passant du temps il doit être possible de faire une implémentation "propre" sur la même idée (ie un truc dans lequel on est sur à 100% qu'un thread n'a pas pu enlever les deux write-lock, changer les valeurs des deux variables et remettre les deux write-lock à l'identique sans que les variables de conditions n'aient le temps d'être mise à jour.)