Discussion:Couplage fort (programmation concurrente)

A voir, les modifications faites aujourd'hui concernent une autre définition du couplage fort.

Je vais passer plus tard pour faire les corrections nécessaires pour faire une scission de l'article et rétablir la version précédente(juste dans le contexte de la programmation concurrente) et faire une deuxième page pour l'utilisation dans l'autre texte. Boretti(me parler) 2 août 2007 à 17:36 (CEST)

Il n'existe pas deux définitions de couplage fort, une pour le génie logiciel et une pour la programmation concurrente. Il existe effectivement des problèmes de synchronisation (très bien connus) dans le cas de fils d'exécution en couplage fort mais on parle alors de ressources non-partageables (nonpreemtable resources). --Nipou 2 août 2007 à 20:19 (CEST)

Le principe de ressource non-partage est lié à la notion de exclusion mutuelle. Dans le cadre de la programmation concurrente, le couplage fort est un défaut possible des des algorithmes d'exclusion mutuelle. Boretti(me parler) 2 août 2007 à 20:30 (CEST)

Il s'agit d'un deadlock tout ce qu'il y a de plus commun, le terme couplage fort entre des fils d'exécution pour décrire leur dépendence fonctionnellle n'est pas du tout reconnu universellement, il s'agit sûrement d'un terme usé seulement par Luigi Zaffalon. Par contre, le terme couplage fort dans le domaine de la programmation existe depuis les années 70-80 et est très, très, très bien connu.--Nipou 2 août 2007 à 21:05 (CEST)

{{Désaccord de pertinence}}

Merci d'utiliser ~~~~ pour signer les interventions (sans séparer les autres interventions de leurs signatures, sinon on ne s'y retrouve pas. Boretti(me parler) 2 août 2007 à 21:49 (CEST)

Si Nipou (d · c · b) pouvait avoir l'amabilité d'expliquer son point du vue cela serait pratique et constructif.

Pour ma part, l'article est sourcé, par un ouvrage de référence (en langue française certes) dans le domaine du la programmation concurrente, ce qui me semble suffisant pour maintenir l'existence de cette page séparément de la page Couplage fort (génie logiciel) (dont je ne conteste en aucun l'existence et qui est aussi sourcé).

Si Nipou (d · c · b) tu penses que cette page n'est pas pertinente, tu peux aussi, si cela te semble nécessaire passer par les PàS pour en demander la suppression.

Sans argument d'ici une semaine (donc le 9 août), je retirerais le bandeau. Boretti(me parler) 2 août 2007 à 21:09 (CEST)

1) L'article est sourcé par un auteur inconnu, ayant publié un ouvrage obscur dans une maison d'édition universitaire.— Le message qui précède, non signé, a été déposé par Nipou (discuter)

Voir http://ppur.epfl.ch/ . Il s'agit de l'éditeur universitaire principal en Suisse Romande. Boretti(me parler) 2 août 2007 à 21:39 (CEST) (Précision supplémentaire, l'ouvrage cité, avec celui spécifique à Ada, ont été cité dans la revue Login, qui a maintenant cessé d'exister, mais était une revue de très bon qualité, avec une bonne diffusion. Boretti(me parler) 2 août 2007 à 21:45 (CEST))

2) La distinction entre un interblocage (deadlock) et le supposé couplage fort n'est pas faite. — Le message qui précède, non signé, a été déposé par Nipou (discuter)

L'interblocage est une conséquence possible d'un couplage fort dans le contexte de la programmation concurrente. Boretti(me parler) 2 août 2007 à 21:39 (CEST)

Donc le couplage fort indique que deux fils d'exécution partage un espace de variable commun, non?— Le message qui précède, non signé, a été déposé par Nipou (discuter)

Non, il indique que les fils d'exécution se passe EXPLICITEMENT la main. Boretti(me parler) 2 août 2007 à 21:47 (CEST)

Oui, mais pour pouvoir se passer EXPLICITEMENT la main, il faut absolument qu'ils partagent un espace de variables commun. Est-il posible que M. Luigi Zaffalon ait utilisé ce terme simplement car ils partagent un espace de variables commun et communiquent via cet espace? — Le message qui précède, non signé, a été déposé par Nipou (discuter)

Non (je viens de relire les livres pour confirmer). Le terme est spécifiquement utilisé pour désigné le fait qu'un algorithme d'exclusion mutuelle utilise une stratégie de passage explicite de la main entre les tâches Boretti(me parler) 2 août 2007 à 22:00 (CEST)

Oui, mais comment réaliser un passage explicite de la main sans espace commun (que cet espace soit en mode usager ou noyau).— Le message qui précède, non signé, a été déposé par Nipou (discuter)

C'est évident qu'il faut un espace mémoire commun, c'est le cas de tous les algorithmes classiques d'exclusion mutuelle en programmation concurrente. D'ailleurs, le but d'une exclusion mutuelle (suivant le contexte bien sûr), c'est justement de protéger l'accès à un espace de mémoire commun. Boretti(me parler) 2 août 2007 à 22:23 (CEST)

Je ne parle pas de l'espace de mémoire commun en exclusion mutuelle mais celle nécessaire pour établir la communication entre les threads (le mutex par exemple). — Le message qui précède, non signé, a été déposé par Nipou (discuter)

« C'est évident qu'il faut un espace mémoire commun, c'est le cas de tous les algorithmes classiques d'exclusion mutuelle en programmation concurrente », donc oui, je parle bien ça. Mais je ne vois pas où cela nous mène Boretti(me parler) 2 août 2007 à 22:51 (CEST)

Non ce n'est pas évident car la plupart des systèmes d'exploitation offrent des mécanismes de gestion des threads en mode noyau (sections critiques et autres) qui permettent de ne pas utiliser de couplage fort entre les threads pour gérer la concurrence. Donc le terme couplage fort désigne un mécanisme de gestion de la concurrence entre thread usant d'un espace commun de variables en mode usager comme le mutex (en mode usager). En ce sens, le concept de couplage fort dans le contexte des threads ne diffère aucunement de celui généralement admis de couplage fort. Par contre, je ne doute pas qu'il soit intéressant de discuter des problèmes que soulève le couplage fort entre threads. Ce que je veux te faire admettre c'est que la notion de couplage fort entre threads n'est pas distincte de celle généralement admise comme étant un couplage fort. — Le message qui précède, non signé, a été déposé par Nipou (discuter)

Sauf que l'utilisation d'une mémoire commune est un détail dans ce cas et n'est pas obligatoire (mais c'est bien le cas dans l'exemple donnée sur la page), ce qui compte c'est qu'il y a passage explicite de la main. On pourrait très bien réaliser un système avec couplage fort (comme défini dans la page) qui n'utilise pas de mémoire commune (vue l'heure tardive dans ma région, je ne vais pas écrire l'algo maintenant, mais je veux bien le faire demain...). Bon, perso, je vais aller dormir, mais on pourra continuer à discuter demain. Boretti(me parler) 2 août 2007 à 23:32 (CEST)

Remarque, pour faire avancer la discussion : la page interblocage donne au moins un exemple de situation d'interblocage non produit par un couplage fort (au sens donné par la page couplage fort). Par contre, il serait peut être mieux de renommer l'article couplage fort (programmation concurrente) pour éviter toute confusion. Boretti(me parler) 2 août 2007 à 21:56 (CEST)

Pour faire avancer la discussion, dans le Pressman de 1992 (troisième édition car la dernière n'en discute pas), Pressman décrit un "spectre" du couplage allant du fort au faible; juste au millieux se trouve le "control coupling".

"At moderate levels coupling is characterized by passage of control between modules. Control coupling is very commun in most software desing... In its simplest form, control is passed via a flag..." (p337)

Donc ce type de couplage est connu depuis longtemps. Par contre, étant au centre, il serait possible de le faire passer du coté fort ou faible... Zaffalon l'a fait passer du côté fort. Remarquons que dans le contexte de la programmation concurrente, c'est normal. En effet, soit que l'on utilise un mécanisme ad hoc de gestion de la concurrence par passage de contrôle, soit que l'on utilise des mécanismes offert par le noyau. Dans "Modern Operating System, Andrew S. Tanenbaum 2nd édition, 2001" décrit en long et en large les mécanismes possibles de gestion de la concurrence. Soit :

• Mutual Exclusion with Busy Waiting

1. Disabling Interrupts
2. Lock Variables
3. Strict Alternation
4. Peterson's Solution
5. The TSL Instruction

• Sleep and Wakeup

1. Semaphores
2. Mutexes
3. Monitors
4. Message Passing

Mais il ne catégorise aucunement les solutions par la notion de couplage. Remarquons que toute solution par attente active utilise nécessairement un couplage fort (du moins moyen). En effet, le fil d'exécution doit nécessairement attendre que le drapeau (flag) se lève.

Si nous examinons maintenant, avec l'éclairage précédent, ta définition de couplage fort (programmation concurrente) nous voyons qu'elle ne permet pas de comprendre de quoi il s'agit réellement.

1. Le couplage fort...est un problème que peut avoir un algorithme d'exclusion mutuelle.
2. Il se produit lorsqu'un algorithme implique un passage de la main explicite entre les thread souhaitant entrer dans une section critique.
3. Si deux taches accèdent à une resource commune (ressource critique) et qu'elle s'exécute en exclusion mutuelle et que l'entrée d'une des taches dans la ressource critique dépend de la sortie de l'autre on dit alors qu'il y a un couplage fort.
4. Si une tache reste bloquée en section critique elle bloque automatiquement l'autre, il y a donc un couplage fort entre ces deux taches.

Au point 1, nous avons le couplage fort comme étant un problème. Cette définition est généralement accepté en ce qui concerne le couplage fort.

Au point 2, tu précices qu'il s'agit d'un passage de la main explicite, ce que je considère comme un passage de contrôle comme le défini Pressman, soit un couplage moyen. Par contre, s'il s'agit bien de méthodes usant d'un verrou en mode usager, le verrou étant bel et bien une entité globale, on peut facilement parler de couplage fort dans ce cas particulier.

Le point 3 détruit complètement toutes mes hypothèses et me rend gaga. Car il s'agit en fait de la définition même d'une section critique, soit qu'une seule tâche ne peut s'exécuter à la fois dans la section et que l'entrée d'une dépend nécessairement de la sortie de l'autre. Par conséquent, j'en déduis que tu parles, finalement, de tâches partageant un espace global de données et qui sont donc en couplage fort.

Le point 4 me fait douter à nouveau car il s'agit du problème général d'une section critique pouvant toujours entraîner l'interblocage.

Puis, pour terminer, tu donnes un exemple d'une exclusion mutuelle avec attente active, l'attente active étant le gros problème des solutions avec verrou en mode usager (verrou en couplage fort).

Finalement, après avoir lu ton article, il m'est impossible de positionner ta définition d'un couplage fort car ta définition est contradictoire.--Nipou 5 août 2007 à 16:09 (CEST)

Hello, je réponds rapidement sur les points précédent :

• Point 1 : « tu précices qu'il s'agit d'un passage de la main explicite, ce que je considère comme un passage de contrôle comme le défini Pressman, soit un couplage moyen » : Tu prends la définition de Pressman ; soit. La définition que j'utilise est celle d'un autre auteur. Où est le problème ? Si, l'auteur est reconnu dans le domaine (programmation concurrente et temps réel) il n'y a pas de problème. Finalement, ces deux auteurs ont une définition différente (rien ne t'empêche t'ajouter dans l'article la deuxième référence et de la comparer à celle que je propose).
• Point 2 : « Par contre, s'il s'agit bien de méthodes usant d'un verrou en mode usager, le verrou étant bel et bien une entité globale, on peut facilement parler de couplage fort dans ce cas particulier. ». Comme dis plus haut, on peut ne pas utiliser de données partagée pour implémenter le protocole d'accès à la section critère (par exemple, un système utilisant la notion d'échange de jeton dans un anneau de système distribué, communiquant par message, pour contrôler l'accès à une ressource partagée, pourrait être du couplage fort, suivant l'implémentation. Dans ce cas, il n'y aurait aucun espace mémoire partagé pour implémenter le protocole d'accès). De plus, on parle d'un concept théorique qui est indépendant du fait que les verrous sont en mode usager ou non.
• Point 3-4 : L'idée de ces phrases est d'illustrer la définition. La première phrase expliqu'il y a passage explicite de la main d'une tâche à une autre. Dans un algorithme sans couplage fort, l'entrée dans la section critique ne dépend pas de la sortie d'une tâche spécifique, mais simplement du fait que la section n'est pas utilisée. La deuxième phrase est juste là pour montrer que cette solution est une cause fréquente d'interblocage (car, je le répète, il n'est pas nécessaire d'avoir un couplage fort pour avoir un interblocage).

Pour l'exemple, il s'agit juste d'un exemple pour illustrer le propos. Il aurait parfaitement été possible de faire un exemple sans utiliser de verrous en mode usage.

Boretti(me parler) 5 août 2007 à 16:43 (CEST)

Ça commence à être plus clair (pas l'article, mais ce que signifie l'article). Malheureusement (et oui encore) la définition que tu donnes semble être celle d'un système multi-tâches coopératif (versus un système préemptif)...

En ce qui concerne le verrou d'un token ring, il s'agit bien d'un couplage fort (couplage externe) mais également moyen... problème de chevauchement de définitions.--Nipou 5 août 2007 à 17:44 (CEST)

Effectivement, un système multi-tâches a comme défaut d'avoir un couplage fort (au sein de l'article). Et oui, il faudrait peut être remanier l'article pour que cela soit plus clair.

Boretti(me parler) 5 août 2007 à 17:47 (CEST)

Pour revenir à la distinction avec un système coopératif et préemptif, ces deux systèmes utilisent un ordonnanceur de tâches (en mode usager pour le coopératif). Dans le cas du coopératif, il faut que la tâche redonne la main à l'ordonnanceur. Si je comprends bien le couplage fort (programmation concurrente), une tâche donnée redonne toujours la main à une autre tâche bien spécifique qui à sont tours fait de même, comme dans un token ring? Il n'y a donc jamais d'ordonnanceur avec ce type de système?

Pas forcément, il peut y avoir un ordonnanceur (tu pourrais très bien utiliser l'algo donné dans l'article dans un système préemptif). Ce qui compte c'est qu'une tâche spécifique va autoriser une autre tâche à pouvoir s'exécuter (devenir éligible) et vice-versa. Après, c'est de toute manière l'ordonnanceur qui décide quelle tâche doit s'exécuter. Boretti(me parler) 5 août 2007 à 18:50 (CEST)

J'ai remanié un peu le texte, le couplage fort comme étant un problème me semblait vague car les problèmes dégagés sont l'attente active et l'interblocage qui ne sont certainement pas des problèmes propres au couplage fort. De plus, la phrase suivante me gène :

« Si une tâche reste bloquée en section critique, elle bloque automatiquement l'autre, il y a donc un couplage fort entre ces deux tâches. »

Nous avons, en effet: interblocage -> couplage fort

A voir nous nous sommes croisés dans nos réponses.... Boretti(me parler) 2 août 2007 à 21:12 (CEST)

Titre de l'article

Pour éviter des confusions, j'ai renommé l'article en précisant qu'il s'agit d'un cas particulier de couplage fort dans la programmation concurrente. Boretti(me parler) 2 août 2007 à 22:17 (CEST)