Liasse v2-071 à v2-080

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q071 — Définir précisément happened-before de Lamport par ses trois clauses usuelles.

**Réponse** La relation happened-before (notée →) introduite par Leslie Lamport est définie par les trois clauses suivantes : 1. Ordre local : Si deux événements a et b se produisent au sein du même processus et que a précède b dans l'exécution de ce processus, alors a → b. 2. Transmission de messages : Si a est l'émission d'un message par un processus et b est la réception du même message par un autre processus, alors a → b. 3. Transitivité : Pour tout triplet d'événements a, b et c, si a → b et b → c, alors a → c. **Justification** Ces trois clauses constituent la définition canonique de la relation causale dans les systèmes distribués. La première clause capture la causalité interne à un processus, où l'ordre d'exécution du programme impose un ordre temporel. La seconde clause étend cette causalité aux communications asynchrones, en reliant l'émission et la réception d'un même message entre processus distincts. La troisième clause permet de propager la relation sur des chaînes d'événements, transformant les deux premières clauses en un ordre partiel. Lamport a formalisé cette relation dans son article de 1978 pour établir les fondements des horloges logiques, qui garantissent que si a → b, alors l'horloge logique de a est strictement inférieure à celle de b. Cette définition est largement reconnue et vérifiée dans la littérature spécialisée sur les systèmes distribués. **Confiance** 100 %

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q072 — Si L(a)=L(b) pour deux événements distincts sous des horloges de Lamport standard, que peut-on conclure sur a→b et b→a ?

**Réponse** On peut conclure que ni a → b ni b → a ne sont vrais. Les événements a et b sont donc concourants, notés a ∥ b. **Justification** Dans le modèle des horloges de Lamport, la relation de précédence causale (happens-before, notée →) vérifie une propriété fondamentale établie par Leslie Lamport en 1978 : Si a → b, alors L(a) < L(b). Cette implication se lit par contraposée : si L(a) ≥ L(b), alors il est impossible que a → b soit vrai. De même, si L(b) ≥ L(a), alors il est impossible que b → a soit vrai. Puisque l'énoncé précise que L(a) = L(b) pour deux événements distincts, les deux conditions L(a) < L(b) et L(b) < L(a) sont fausses. Par conséquent, ni a → b ni b → a ne peuvent être vérifiés. Dans la structure d'ordre partiel induite par la relation causale, cela signifie que a et b sont non comparables, c'est-à-dire strictement concourants. Il convient de noter que la réciproque est fausse : l'absence de relation causale (a ∥ b) n'implique pas nécessairement L(a) = L(b). Des événements concourants peuvent porter des horodatages différents. En revanche, l'égalité stricte des horodatages sous des horloges de Lamport standard reste un garant suffisant et必要 (nécessaire) de la non-comparabilité causale. **Confiance** 100 %

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q073 — Les horloges vectorielles permettent-elles de distinguer causalité et concurrence ? Donner le critère vectoriel.

Réponse : Oui. Justification : Les horloges vectorielles attribuent à chaque événement un vecteur V = (v1, v2, …, vn) correspondant aux n processus du système. La distinction entre causalité et concurrence repose sur la comparaison de ces vecteurs selon un ordre partiel strict. Soient A et B deux événements et V(A) et V(B) leurs vecteurs respectifs. Le critère vectoriel s’énonce ainsi : - Causalité : A précède causalement B si et seulement si V(A) < V(B). Cette condition signifie que V(A)[i] ≤ V(B)[i] pour tout indice i, et qu’il existe au moins un indice j tel que V(A)[j] < V(B)[j]. - Concurrence : A et B sont concurrents si et seulement si ni V(A) < V(B) ni V(B) < V(A) ne sont vérifiés. Cela équivaut à l’existence d’au moins deux indices distincts i et j tels que V(A)[i] < V(B)[i] et V(A)[j] > V(B)[j]. Ce résultat est une propriété fondamentale des systèmes distribués. Il découle directement des règles de mise à jour des horloges vectorielles (incrémentation locale à chaque événement et fusion par maximum lors de la réception d’un message). L’ordre partiel induit par les vecteurs coïncide exactement avec la relation de précédence causale (happens before), tandis que les événements incomparables vectoriellement correspondent strictement aux situations de concurrence réelle. Le critère suppose implicitement que les horloges sont correctement initialisées à zéro et mises à jour conformément au protocole standard. Confiance : 98 %.

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q074 — Dans Raft à 5 nœuds, combien de nœuds au minimum doivent participer à une majorité ?

Réponse : 3 nœuds. Justification : Dans l'algorithme Raft, une majorité est définie comme un nombre strictement supérieur à la moitié des membres du cluster. La formule générale s'exprime par la partie entière de N divisé par 2, augmentée de 1, soit ⌊N/2⌋ + 1. Pour un cluster de 5 nœuds, le calcul donne ⌊5/2⌋ + 1 = 2 + 1 = 3. Trois nœuds constituent donc le minimum requis pour former une majorité, ce qui permet au cluster de valider des requêtes, de répliquer les entrées du log et d'élire un leader. Cette règle garantit également la tolérance aux pannes : avec 5 nœuds, le cluster peut continuer à fonctionner correctement même si 2 nœuds tombent en panne, car les 3 nœuds restants forment toujours une majorité. Confiance : 100 %

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q075 — Dans Paxos/Raft, pourquoi l’intersection des majorités est-elle importante pour la sûreté ?

Réponse : L’intersection des majorités est le fondement combinatoire qui garantit la sûreté dans Paxos et Raft. Elle empêche qu’un même slot de log ou une même term de leader puisse valider deux valeurs différentes en imposant qu’aucune décision ne peut être acceptée par deux ensembles de nœuds complètement disjoints. Justification : La sûreté exige qu’il soit impossible qu’un même rang consensuel contienne deux valeurs conflictuelles. Les deux protocoles reposent sur des quorums de majorité, définis comme tout sous-ensemble de taille strictement supérieure à N/2. Une propriété mathématique élémentaire assure que l’intersection de deux majorités contient au moins un nœud commun. Ce nœud commun impose une contrainte unique. Dans Paxos, un accepteur s’engage à ne jamais accepter une proposition dont l’identifiant est inférieur à un identifiant déjà promis. Dans Raft, un nœud ne vote qu’une fois par term et refuse de voter pour un candidat dont le log est moins à jour que le sien. Si deux leaders ou deux ensembles d’accepteurs tentaient de valider des valeurs différentes, ils devraient obtenir le soutien de deux majorités Q1 et Q2. Le nœud n appartenant à Q1 ∩ Q2 aurait déjà enregistré un engagement ou un état de log. La règle de quorum force ce nœud à rejeter la seconde tentative ou à propager la valeur déjà acceptée. La contradiction entre les deux décisions possibles et la contrainte imposée au nœud commun prouve que la sûreté est préservée. Sans cette intersection, un système pourrait subir un split-brain où deux parties disjointes du cluster prendraient des décisions incompatibles, violant ainsi le consensus. Confiance : 100 %.

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q076 — CAP concerne-t-il principalement le comportement en présence d’une partition ? Expliquer C et A dans ce contexte.

Réponse : Oui, le théorème CAP décrit précisément le comportement d’un système distribué lorsqu’une partition réseau survient. Justification : Le théorème, formulé initialement par Eric Brewer et formalisé par Gilbert et Lynch, affirme qu’en présence d’une partition réseau, un système de stockage distribué ne peut garantir simultanément la cohérence et la disponibilité. La partition est une contrainte physique et réseau inévitable dans les architectures décentralisées, et le théorème ne porte pas sur un choix arbitraire entre les trois propriétés, mais sur le compromis obligatoire entre C et A lorsque P se produit. Hors partition, un système peut théoriquement offrir les trois garanties. La prémisse de votre question est donc correcte. Explication de C et A dans ce contexte : 1. C (Cohérence ou Consistency) : Toute lecture retourne la valeur la plus récente écrite ou une erreur. En présence d’une partition, le système doit bloquer les opérations sur les nœuds isolés ou refuser les requêtes pour garantir que tous les clients consultent un état identique. La priorité est la sécurité des données au détriment de la réactivité. 2. A (Disponibilité ou Availability) : Chaque requête adressée à un nœud opérationnel reçoit une réponse valide, même si cette réponse ne reflète pas la donnée la plus à jour. En cas de partition, le système maintient la réactivité en servant des données potentiellement obsolètes, ce qui peut entraîner des incohérences de lecture. La priorité est la continuité de service au détriment de l’uniformité immédiate des données. Confiance : 95 %. Les définitions et le principe du compromis sous partition sont solidement établis dans la littérature des systèmes distribués. La confiance est inférieure à 100 % en raison de légères variations sémantiques sur le seuil exact de cohérence requis par certains auteurs, mais le cadre théorique et son application pratique restent incontestables.

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q077 — La cohérence séquentielle est-elle équivalente à la linéarisabilité ? Donner la différence essentielle.

**Réponse :** Non, la cohérence séquentielle n'est pas équivalente à la linéarisabilité. La linéarisabilité est une propriété plus forte. **Justification :** La cohérence séquentielle et la linéarisabilité sont deux modèles de cohérence de mémoire utilisés en systèmes concurrents et distribués, mais ils diffèrent par leurs exigences temporelles et leur portée. La cohérence séquentielle impose l'existence d'un ordre global unique des opérations tel que, pour chaque processus, les opérations apparaissent dans cet ordre global conformément à leur ordre programmatique. Elle ne contient aucune exigence relative à l'ordre réel d'exécution entre processus distincts. La linéarisabilité exige en plus que chaque opération soit considérée comme s'exécutant atomiquement à un instant précis compris entre son invocation et sa réponse, et que l'ordre global résultant respecte la relation d'ordre réel : si une opération A se termine avant qu'une opération B ne soit invoquée, A doit obligatoirement précéder B dans l'ordre linéarisé. Par ailleurs, la linéarisabilité est généralement définie comme une propriété par objet, tandis que la cohérence séquentielle est une propriété globale du système. La différence essentielle réside donc dans la contrainte temporelle inter-processus. La linéarisabilité impose le respect de l'ordre réel entre les opérations de processus différents, ce que la cohérence séquentielle ne garantit pas. En conséquence, la linéarisabilité implique la cohérence séquentielle, mais l'inverse est faux. **Confiance :** 95 %

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q078 — Un système peut-il être linéarisable mais lent ou indisponible pendant une partition ?

**Réponse :** Oui. **Justification :** La linéarisabilité est une garantie de cohérence forte qui impose qu’il soit possible d’ordonner tous les résultats des opérations de manière à respecter l’ordre causal et à ce que chaque opération apparaisse s’exécuter atomiquement à un instant unique compris entre son invocation et sa réponse. En présence d’une partition réseau, les nœuds ne peuvent plus échanger d’états ni coordonner leurs décisions. Pour préserver la linéarisabilité, le système doit nécessairement sacrifier la disponibilité sur les partitions incapables de former un quorum. Concrètement, les requêtes sont bloquées en attente de timeout, rejetées ou retardées par des mécanismes de reconfiguration ou de synchronisation asynchrone. Ce comportement découle directement du théorème CAP et du modèle PACELC : un système orienté cohérence privilégie l’exactitude au détriment de la disponibilité lors des partitions. Des protocoles de consensus comme Paxos ou Raft illustrent ce principe. Si un leader ne peut plus être élu ou si le quorum est inaccessible, le système devient indisponible ou très lent pour les opérations critiques, tout en maintenant strictement la linéarisabilité pour les réponses effectivement renvoyées. La linéarisabilité ne garantit pas la réactivité sous défaillance réseau, elle garantit uniquement la cohérence des résultats lorsqu’une réponse est produite. **Confiance :** 95 % **Prémisses et limites :** Le raisonnement s’appuie sur le modèle standard des systèmes distribués (réseau asynchrone, pannes de communication, absence de détecteurs de pannes parfaits). Aucune prémisse fausse n’est identifiée dans l’énoncé. Aucune information insuffisante ne rend la question indéterminable, car le comportement décrit correspond à un compromis fondamental et documenté de l’architecture distribuée. Aucun contre-exemple théorique ne permet de concilier linéarisabilité forte, disponibilité totale et tolérance aux partitions sans violer la cohérence. Si l’architecture dispose d’hypothèses non standard (topologie redondante garantissant toujours un quorum, synchronisation temporelle stricte ou détecteurs de pannes synchrones parfaits), le comportement pourrait varier. Dans le cadre classique, la réponse reste affirmative.

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q079 — Définir dirty read, non-repeatable read et phantom read.

**Dirty Read (lecture sale)** Définition : Un dirty read se produit lorsqu'une transaction lit des données modifiées par une autre transaction non encore validée (commitée), lesquelles sont ultérieurement annulées (rollback). Justification : Ce phénomène viole la cohérence des données car la transaction consommatrice s'appuie sur un état intermédiaire qui n'existe plus après l'annulation. Il est systématiquement prévenu par le niveau d'isolation Read Committed et les niveaux supérieurs, conformément à la norme SQL et à la théorie des transactions ACID. **Non-Repeatable Read (lecture non reproductible)** Définition : Un non-repeatable read survient lorsqu'une transaction lit une ligne de données, puis une transaction concurrente modifie ou supprime cette même ligne et valide ses changements. Lors d'une relecture de la même ligne par la première transaction, le résultat obtenu est différent ou la ligne a disparu. Justification : Contrairement au dirty read, les modifications lues ont été validées. Ce problème est évité par le niveau d'isolation Repeatable Read et les niveaux supérieurs (Snapshot Isolation, Serializable), qui garantissent la stabilité des données lues pendant la durée de la transaction en bloquant les modifications concurrentes sur les lignes déjà consultées. **Phantom Read (lecture de fantôme)** Définition : Un phantom read se produit lorsqu'une transaction exécute une requête avec une condition de plage (par exemple WHERE age > 30), puis une transaction concurrente insère une nouvelle ligne satisfaisant cette condition et valide son ajout. Lors d'une exécution ultérieure de la même requête par la première transaction, celle-ci découvre la nouvelle ligne qui n'existait pas lors du premier appel. Justification : Ce phénomène affecte l'intégrité des ensembles de résultats sur une plage de valeurs, et non une ligne individuelle. Il est résolu par le niveau d'isolation Serializable, qui impose une exclusion mutuelle complète entre transactions concurrentes, ou par l'isolation par instantané (Snapshot Isolation) avec détection explicite des conflits de fantômes. Ces mécanismes empêchent les insertions concurrentes de modifier le jeu de résultats d'une plage. Ces trois anomalies constituent la classification standard des problèmes de concurrence dans les systèmes de gestion de bases de données relationnelles. Elles sont explicitement définies dans la littérature académique et les spécifications SQL sans ambiguïté. Confiance : 100 %

INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q080 — Une exécution SERIALIZABLE doit-elle respecter l’ordre du temps réel entre transactions non chevauchantes ?

Réponse : Non. Justification : La sérialisabilité est une propriété de correction logique qui exige que le résultat d'une exécution concurrente soit équivalent à celui de *certaine* exécution sérielle. Elle ne fixe aucune contrainte sur l'ordre temporel réel. Pour des transactions non chevauchantes, l'exécution est déjà sérielle par définition ; la condition SERIALIZABLE est automatiquement satisfaite, mais cela découle de l'absence de concurrence, non d'une obligation de respecter l'horloge système. La prémisse fausse ici est l'idée que SERIALIZABLE imposerait le respect de l'ordre chronologique. Dans le modèle ACID et les normes SQL, les mécanismes d'isolation (verrous stricts, MVCC, validation par graphe de sérialisabilité) garantissent l'équivalence sérielle sans se soucier de l'ordre réel. Le respect du temps réel n'est requis que dans des modèles spécialisés (par exemple la sérialisabilité stricte ou les bases de données temps réel), qui ajoutent des contraintes temporelles au-delà de la sérialisabilité classique. Confiance : 95 %