LANXAS White, Blind Benchmark v2.0, liasse v2-071 à v2-080

Liasse de consultation : copie conforme, octet pour octet, des exécutions gelées du 21 août 2026. Les pages individuelles test-v2-NNN.html restent la référence opposable, chaque réponse est vérifiable par son SHA-256. Aucune ré-exécution, aucune modification.

Index des 12 liasses · Registre officiel

Copie v2-071

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui porte sur un concept fondamental des systèmes distribués.

La relation happened-before (notée →), introduite par Leslie Lamport en 1978 dans son article fondateur « Time, Clocks, and the Ordering of Events in a Distributed System », est définie par trois clauses. Elle s'applique à un ensemble d'événements E d'un système distribué, où chaque événement est associé à un processus.

Première clause, l'ordre local. Si a et b sont deux événements du même processus, et que a survient avant b dans l'ordre d'exécution de ce processus, alors a → b. Autrement dit, la relation d'ordre total propre à chaque processus est incluse dans happened-before.

Deuxième clause, la communication entre processus. Si a est l'envoi d'un message par un processus et b est la réception de ce même message par un autre processus, alors a → b. Cette clause capture l'idée que la réception d'un message ne peut survenir qu'après son envoi.

Troisième clause, la transitivité. Si a → b et b → c, alors a → c. Cette clause étend la relation par fermeture transitive.

Il est important de préciser que happened-before est une relation d'ordre partiel strict : deux événements distincts peuvent être incomparables, auquel cas on dit qu'ils sont concurrents (ni a → b, ni b → a). C'est précisément cette propriété qui distingue l'ordre partiel de Lamport d'un ordre total.

Une remarque de rigueur : la définition usuelle se formule souvent comme la plus petite relation satisfaisant ces trois conditions, ce qui revient à la fermeture transitive de l'union de l'ordre local et de la relation d'envoi-réception. Cette précision évite d'admettre des relations qui ne découleraient pas réellement de la causalité.

Confiance : 97 %. Cette définition est un résultat standard, énoncé de mémoire avec une formulation canonique bien établie ; la marge restante tient à la variété des présentations possibles dans la littérature, sans que le fond en soit affecté.

Copie v2-072

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Bonjour. Je vous remercie pour cette question portant sur les horloges de Lamport.

**Réponse**

Si L(a) = L(b) pour deux événements distincts a et b sous des horloges de Lamport standard, alors on ne peut conclure ni a→b, ni b→a. En d'autres termes, les deux relations de précédence causale sont fausses : ni a ne précède causalement b, ni b ne précède causalement a.

**Justification**

Rappelons la propriété fondamentale des horloges de Lamport : si a→b (a précède causalement b), alors L(a) < L(b). Cette implication est une conséquence directe de la règle de mise à jour de l'horloge : chaque processus incrémente son compteur local avant d'horodater un événement, et les messages transportent l'horloge de l'émetteur, le récepteur prenant le maximum de son compteur et de la valeur reçue, puis l'incrémentant.

Par contraposition, si L(a) = L(b), alors on ne peut pas avoir a→b, car cela exigerait L(a) < L(b). De même, on ne peut pas avoir b→a, car cela exigerait L(b) < L(a). Les deux relations sont donc exclues.

Il faut toutefois être précis sur la portée de cette conclusion. L'égalité des horodatages ne prouve pas à elle seule que les événements sont concurrents au sens strict de la définition (a ∥ b signifie ni a→b ni b→a). En effet, l'égalité L(a) = L(b) exclut bien les deux précédences, donc elle implique effectivement la concurrence a ∥ b. Mais l'inverse n'est pas vrai : deux événements concurrents peuvent très bien recevoir des horodatages différents. L'horloge de Lamport est un mécanisme de cohérence, pas une horloge vectorielle : elle ne capture pas complètement l'ordre causal, et c'est précisément la raison pour laquelle les horloges vectorielles ont été introduites.

Ainsi, la conclusion exacte est : L(a) = L(b) implique que a et b sont concurrents (a ∥ b), c'est-à-dire ni a→b ni b→a. En revanche, la réciproque est fausse.

**Confiance**

Je place ma confiance à 97 %. Cette déduction repose sur une propriété standard et bien établie des horloges de Lamport, que je peux vérifier par le raisonnement de contraposition exposé ci-dessus. La petite marge restante tient au fait que j'énonce de mémoire une propriété classique de la littérature distribuée, sans pouvoir ici consulter la source originale.

Je reste à votre disposition pour toute précision complémentaire.

Copie v2-073

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui porte sur un concept fondamental des systèmes distribués.

## Réponse

Oui, les horloges vectorielles permettent précisément de distinguer la causalité de la concurrence entre deux événements. C'est leur propriété essentielle, qui les distingue des horloges de Lamport (qui ne fournissent qu'un ordre partiel sans pouvoir discriminer la concurrence).

## Critère vectoriel

Soit deux événements a et b, d'horloges vectorielles respectives V(a) et V(b), où chaque vecteur a une composante par processus.

L'événement a précède causalement b (noté a → b) si et seulement si :

V(a) < V(b), c'est-à-dire que pour tout processus i, V(a)[i] ≤ V(b)[i], et il existe au moins un processus j tel que V(a)[j] < V(b)[j].

Les événements a et b sont concurrents (noté a ∥ b) si et seulement si ni V(a) < V(b) ni V(b) < V(a) ne sont vérifiés, c'est-à-dire s'il existe deux processus distincts i et j tels que V(a)[i] > V(b)[i] et V(a)[j] < V(b)[j].

## Justification

La propriété de comparaison forte des horloges vectorielles garantit l'équivalence exacte entre l'ordre causal et l'ordre vectoriel :

a → b si et seulement si V(a) < V(b).

Cette équivalence bidirectionnelle est ce qui permet de trancher sans ambiguïté entre les trois cas possibles : causalité dans un sens, causalité dans l'autre, ou concurrence. En effet, si deux vecteurs ne sont pas comparables (aucun n'est inférieur à l'autre dans toutes ses composantes), alors les événements correspondants sont nécessairement concurrents : aucun chemin de messages ne les relie.

## Vérification par un exemple

Considérons trois processus P1, P2, P3. Initialement, tous les vecteurs valent (0, 0, 0).

P1 exécute un événement local : V = (1, 0, 0). Puis P1 envoie un message à P2 ; P2 reçoit et met à jour : V = (1, 1, 0). P2 exécute un événement b : V(b) = (1, 2, 0).

Pendant ce temps, P3 exécute un événement c : V(c) = (0, 0, 1).

Comparons b et c : V(b) = (1, 2, 0) et V(c) = (0, 0, 1). On a V(b)[1] = 1 > 0 = V(c)[1], mais V(b)[3] = 0 < 1 = V(c)[3]. Les vecteurs ne sont pas comparables, donc b et c sont concurrents, ce qui est correct : aucun message ne les relie.

Comparons a et b : V(a) = (1, 0, 0) et V(b) = (1, 2, 0). On a V(a)[1] = 1 ≤ 1, V(a)[2] = 0 ≤ 2, V(a)[3] = 0 ≤ 0, avec V(a)[2] < V(b)[2]. Donc V(a) < V(b), et a → b, ce qui est correct puisque le message de P1 vers P2 relie causalement les deux événements.

## Confiance

Je formule cette réponse avec une confiance de 97 %. La définition du critère vectoriel et son équivalence avec l'ordre causal sont des résultats standards et solidement établis de la théorie des systèmes distribués ; ma réserve de quelques points provient uniquement du fait que je récite ces définitions de mémoire, sans pouvoir les vérifier contre une source sous les yeux.

Je reste à votre disposition pour approfondir, par exemple sur la comparaison avec les horloges de Lamport ou sur les mécanismes de taille des vecteurs.

Copie v2-074

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Cher utilisateur,

Je vous remercie pour cette question portant sur le fonctionnement du consensus Raft. Voici ma réponse détaillée.

La question porte sur le consensus Raft à 5 nœuds. Dans Raft, une majorité, également appelée quorum, est définie comme la moitié des nœuds plus un. Pour un cluster de 5 nœuds, la majorité est donc de 3 nœuds.

Réponse : 3 nœuds.

Justification : Raft exige qu'une élection ou une écriture soit approuvée par une majorité stricte des nœuds du cluster. Avec N égal à 5, la majorité est floor(N/2) + 1, soit 2 + 1, ce qui donne 3. Ce quorum garantit qu'au plus un leader peut être élu à la fois et que les entrées du journal sont dupliquées sur une majorité de nœuds. En effet, avec 5 nœuds, deux majorités distinctes de 3 nœuds chacune se chevauchent nécessairement en au moins un nœud, ce qui empêche l'élection simultanée de deux leaders et assure la cohérence des journaux.

Confiance : 97 %. Il s'agit d'une définition standard du consensus Raft, bien établie dans la littérature, notamment dans l'article fondateur de Diego Ongaro et John Ousterhout. La formule de majorité est une règle formelle simple, mais je plafonne légèrement ma confiance car ma mémoire n'est pas une source infaillible pour une citation exacte.

Je reste à votre disposition pour toute précision complémentaire.

Cordialement.

Copie v2-075

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui touche au cœur de la conception des algorithmes de consensus répliqué.

**Réponse**

Dans Paxos et Raft, l'intersection des majorités est le mécanisme fondamental qui garantit la propriété de sûreté (safety), c'est-à-dire qu'aucune valeur conflictuelle ne peut être décidée à des étapes différentes. La raison est purement combinatoire : dans un système de N processus, toute paire de majorités (ensembles de plus de N/2 processus) a une intersection non vide. Cette propriété assure qu'un processus qui a participé à une décision passée sera nécessairement consulté lors de toute tentative ultérieure de décision.

**Justification détaillée**

Considérons N processus. Une majorité est un ensemble de taille strictement supérieure à N/2. Si deux majorités M₁ et M₂ étaient disjointes, on aurait |M₁| + |M₂| ≤ N, donc 2·(N/2) < |M₁| + |M₂| ≤ N, ce qui est impossible puisque |M₁| + |M₂| > N. L'intersection est donc toujours non vide.

Cette propriété est exploitée de la manière suivante. Dans Paxos, un accepteur qui a accepté une valeur v pour un numéro de round n doit, lors de tout round ultérieur, communiquer cette valeur au proposant. Comme le quorum de préparation (prepare) du nouveau round et le quorum d'acceptation (accept) du round précédent se recoupent, le proposant apprend nécessairement la valeur déjà acceptée et doit la proposer à nouveau. Ainsi, une fois qu'une valeur est choisie, toute valeur choisie ultérieurement lui est identique : c'est la sûreté.

Dans Raft, le même principe s'applique via l'élection du leader. Un candidat doit obtenir les votes d'une majorité pour devenir leader. Comme le leader précédent avait été élu par une majorité, et que le nouveau leader est élu par une autre majorité, ces deux majorités se recoupent. Le nouveau leader rencontre donc au moins un serveur qui connaît l'état du leader précédent, et il doit répliquer les entrées de journal de ce serveur avant d'en accepter de nouvelles. Cela empêche deux leaders successifs de commettre des entrées contradictoires.

**Point de rigueur**

Il faut distinguer sûreté et vivacité (liveness). L'intersection des majorités garantit la sûreté : elle empêche que deux valeurs différentes soient décidées. Elle ne garantit pas à elle seule la vivacité, c'est-à-dire qu'une décision soit effectivement prise ; c'est pourquoi Paxos et Raft imposent des conditions supplémentaires (comme l'unicité des numéros de round ou l'élection d'un leader unique à un instant donné) pour assurer le progrès.

**Confiance : 96 %.** Cette explication repose sur une propriété combinatoire démontrable (l'intersection non vide des majorités) et sur la structure bien établie de Paxos et Raft, que je connais avec une grande fiabilité. La marge restante tient à la formulation des détails d'implémentation, qui varient selon les présentations.

Je reste à votre disposition pour approfondir, par exemple sur la distinction entre les phases de Paxos ou sur la gestion des entrées de journal dans Raft.

Copie v2-076

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question, qui porte sur le théorème CAP, un résultat fondamental des systèmes distribués.

**Réponse**

Oui, le théorème CAP concerne précisément le comportement d'un système distribué en présence d'une partition du réseau. Il énonce qu'un système distribué ne peut garantir simultanément les trois propriétés suivantes :

**C — Cohérence (Consistency)** : tous les nœuds voient les mêmes données au même moment. Autrement dit, après une écriture réussie, toute lecture ultérieure renvoie la valeur la plus récente, quel que soit le nœud interrogé. C'est une cohérence forte, linéarisable.

**A — Disponibilité (Availability)** : chaque requête reçue par un nœud non défaillant reçoit une réponse, sans erreur ni délai infini. Le système continue de répondre même si certains nœuds sont inaccessibles.

**P — Tolérance au partitionnement (Partition tolerance)** : le système continue de fonctionner correctement même si le réseau est divisé en plusieurs sous-réseaux qui ne peuvent plus communiquer entre eux.

**Le point central du théorème**

Lorsqu'une partition se produit, le réseau est coupé en deux groupes de nœuds qui ne peuvent plus échanger d'informations. Dans cette situation, le système doit choisir :

Soit il privilégie la cohérence (C) et sacrifie la disponibilité (A) : il refuse de répondre aux requêtes qui ne peuvent pas être servies avec certitude, pour éviter de renvoyer des données obsolètes. C'est le choix de systèmes comme ZooKeeper ou etcd.

Soit il privilégie la disponibilité (A) et sacrifie la cohérence (C) : chaque partition continue de répondre, mais les deux groupes peuvent diverger temporairement, jusqu'à ce que la partition soit résolue et que les données soient reconciliées. C'est le choix de systèmes comme Cassandra ou DynamoDB.

Le théorème, proposé par Eric Brewer en 2000 puis prouvé formellement par Gilbert et Lynch en 2002, établit qu'il est impossible de garantir les trois propriétés à la fois en présence d'une partition. Comme une partition est inévitable dans un réseau réel, le choix pratique se réduit à CP ou AP. La tolérance au partitionnement (P) n'est donc pas réellement optionnelle : elle est une condition du monde réel, et le vrai arbitrage se joue entre C et A.

**Confiance : 96 %.** Cette confiance est élevée car il s'agit d'un résultat standard et bien établi de l'informatique distribuée, que je connais avec certitude. Je laisse une petite marge car la formulation précise des définitions peut varier légèrement selon les sources, mais le fond du théorème est incontestable.

Copie v2-077

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Madame, Monsieur,

Je vous remercie pour cette question qui touche à un point fondamental de la théorie des objets partagés concurrents. Permettez-moi de vous apporter une réponse précise et complète.

La cohérence séquentielle et la linéarisabilité ne sont effectivement pas équivalentes. Ce sont deux garanties de cohérence distinctes pour les objets partagés concurrents, et la différence essentielle réside dans la relation entre l'ordre des opérations et le temps réel.

La linéarisabilité exige que chaque opération prenne effet en un point précis de l'ordre réel, appelé point de linéarisation, situé entre son invocation et sa réponse. L'ordre linéarisé doit donc respecter l'ordre réel des opérations non chevauchantes : si une opération se termine avant qu'une autre ne commence, la première doit précéder la seconde dans l'ordre linéarisé. C'est une propriété dite de temps réel.

La cohérence séquentielle, en revanche, n'impose aucune contrainte de temps réel. Elle exige seulement qu'il existe un ordre séquentiel total des opérations, cohérent avec l'ordre programmé de chaque processus individuel, et que chaque opération lise la valeur de la dernière écriture qui la précède dans cet ordre. Mais cet ordre peut réordonner librement des opérations de processus différents, même si elles sont séparées dans le temps réel.

Ainsi, toute exécution linéarisable est séquentiellement cohérente, mais la réciproque est fausse : une exécution peut être séquentiellement cohérente sans être linéarisable, dès lors que l'ordre séquentiel choisi viole l'ordre réel des opérations non concurrentes.

Un exemple classique illustre la différence. Considérons deux processus P1 et P2 qui écrivent chacun une valeur distincte dans un registre partagé initialisé à 0, puis lisent le registre. P1 écrit 1 puis lit 1 ; P2 écrit 2 puis lit 2. L'exécution est séquentiellement cohérente : l'ordre séquentiel P1 écrit 1, P2 écrit 2, P1 lit 1, P2 lit 2 convient, chaque processus voyant sa propre écriture. Mais si, dans le temps réel, P1 a terminé son écriture et sa lecture avant que P2 ne commence la sienne, alors la linéarisabilité exigerait que P1 précède P2 dans l'ordre ; or P1 lit 1 alors que P2 a écrit 2 après, ce qui est impossible dans un ordre linéarisé respectant le temps réel. L'exécution est donc séquentiellement cohérente mais non linéarisable.

En résumé, la linéarisabilité est une propriété plus forte : elle ajoute la contrainte de temps réel à la cohérence séquentielle. C'est pourquoi la linéarisabilité est souvent préférée pour les structures de données concurrentes, car elle permet de raisonner sur les exécutions comme si elles étaient atomiques et ordonnées dans le temps.

Confiance : 97 %. Cette distinction est un résultat standard et bien établi de la théorie de la cohérence mémoire et des objets partagés, que je peux vérifier par la définition formelle des deux propriétés.

Je reste à votre disposition pour toute précision complémentaire.

Cordialement.

Copie v2-078

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Bonjour et merci pour cette question qui touche à des notions fondamentales des systèmes distribués.

**Réponse**

Oui, un système peut tout à fait être linéarisable tout en étant lent ou indisponible pendant une partition. La linéarisabilité et la performance (latence, disponibilité) sont des propriétés orthogonales d'un système distribué.

**Justification**

La linéarisabilité est une propriété de cohérence : elle garantit que les opérations concurrentes apparaissent comme si elles s'exécutaient dans un ordre séquentiel cohérent avec le temps réel. Elle ne dit rien sur la vitesse d'exécution ni sur la disponibilité.

Plus précisément, un système linéarisable peut être lent pour plusieurs raisons.

D'abord, la linéarisabilité impose souvent une synchronisation. Les implémentations classiques, par exemple un registre linéarisable, exigent qu'une opération d'écriture attende la confirmation d'un quorum de réplicas avant de répondre. Cette attente réseau, ce coût de coordination, peut rendre le système lent même s'il est parfaitement linéarisable.

Ensuite, la linéarisabilité n'impose aucune borne de latence. Un système peut être linéarisable avec des temps de réponse arbitrairement longs, pourvu que l'ordre des opérations reste cohérent avec le temps réel. La propriété est sémantique, pas temporelle au sens de la performance.

Enfin, concernant la disponibilité pendant une partition : c'est un résultat classique, le théorème CAP dans sa formulation moderne, qu'un système linéarisable ne peut pas rester disponible pendant une partition réseau. En effet, pour garantir la linéarisabilité, il faut pouvoir distinguer une opération qui a réellement eu lieu avant la partition d'une opération concurrente ; cela exige de communiquer avec les réplicas de l'autre côté de la partition, ce qui est impossible. Le système doit donc soit refuser de servir, ce qui le rend indisponible, soit sacrifier la linéarisabilité.

Ainsi, pendant une partition, un système linéarisable est nécessairement indisponible, ou du moins ne peut pas garantir à la fois disponibilité et linéarisabilité. Et en fonctionnement normal, il peut être lent en raison des coûts de coordination inhérents à la garantie de linéarisabilité.

**Confiance : 94 %**

Cette réponse repose sur des résultats établis de la théorie des systèmes distribués, notamment la définition de la linéarisabilité par Herlihy et Wing et le théorème CAP dans sa formulation moderne. La confiance est élevée mais pas maximale car je m'appuie sur des résultats standards énoncés de mémoire, sans vérification formelle dans cette session.

Je vous remercie pour cette question stimulante et reste à votre disposition pour toute précision complémentaire.

Copie v2-079

Question (verbatim)

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.

Réponse intégrale (verbatim, hachée ci-dessus)

Bonjour, et merci pour cette question portant sur les anomalies de concurrence dans les bases de données transactionnelles. Je vais vous définir ces trois phénomènes avec précision.

**Dirty read (lecture sale)**

Un dirty read se produit lorsqu'une transaction lit une donnée qui a été modifiée par une autre transaction encore non validée, c'est-à-dire non commitée. Si cette seconde transaction est ensuite annulée, par un rollback, la première transaction a utilisé une valeur qui n'a jamais existé de manière durable dans la base. La donnée lue est donc qualifiée de sale, au sens où elle provient d'un état intermédiaire et potentiellement éphémère.

**Non-repeatable read (lecture non répétable)**

Ce phénomène survient lorsqu'une transaction lit une même ligne à deux reprises et obtient des valeurs différentes. Entre les deux lectures, une autre transaction a validé une modification, qu'il s'agisse d'une mise à jour ou d'une suppression, portant sur cette ligne. La première transaction, qui s'attendait à une lecture stable, constate une incohérence entre ses deux lectures.

**Phantom read (lecture fantôme)**

Un phantom read se produit lorsqu'une transaction exécute deux fois une même requête de sélection portant sur un ensemble de lignes, par exemple une requête avec une condition WHERE, et obtient des ensembles différents. Entre les deux exécutions, une autre transaction a validé l'insertion ou la suppression de lignes qui satisfont la condition. Les nouvelles lignes apparaissent comme des fantômes, car elles n'existaient pas lors de la première lecture.

**Distinction essentielle**

La différence clé entre non-repeatable read et phantom read tient à la granularité : le premier concerne une ligne unique dont la valeur change, tandis que le second concerne l'ensemble des lignes retournées par une requête, dont la composition change par insertion ou suppression. Le dirty read, lui, se distingue par le fait qu'il implique une transaction non validée, alors que les deux autres impliquent des transactions validées.

Ces trois anomalies sont précisément celles que le standard SQL définit pour classer les niveaux d'isolation, à savoir Read Uncommitted, Read Committed, Repeatable Read et Serializable. Chaque niveau supérieur élimine certaines de ces anomalies, le niveau Serializable étant le seul à les prévenir toutes.

Ma confiance dans ces définitions est élevée, de l'ordre de 94 %, car il s'agit de notions standard du modèle transactionnel SQL, que je restitue de mémoire avec soin. Si vous souhaitez approfondir le lien avec les niveaux d'isolation, je serai ravi de poursuivre.

Copie v2-080

Question (verbatim)

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 intégrale (verbatim, hachée ci-dessus)

Je vous remercie pour cette question précise, qui touche au cœur de la théorie des transactions et des niveaux d'isolation.

**Réponse**

Oui, une exécution sérialisable doit respecter l'ordre du temps réel entre transactions non chevauchantes, à condition de se placer dans la définition forte de la sérialisabilité, celle qui est retenue dans les systèmes de gestion de bases de données modernes et dans la littérature sur les transactions distribuées.

**Justification**

La sérialisabilité, au sens de la définition classique, impose que l'exécution soit équivalente à une exécution séquentielle des transactions. Or, si deux transactions T1 et T2 ne se chevauchent pas dans le temps, c'est-à-dire si T1 se termine entièrement avant que T2 ne commence, alors tout ordre séquentiel équivalent doit placer T1 avant T2. En effet, une transaction qui a déjà commis ses effets ne peut pas être déplacée après une transaction qui a commencé plus tard sans violer la sémantique des opérations observées. Cette exigence est formalisée par la notion de sérialisabilité avec préservation du temps réel, qui est le niveau d'isolation le plus fort, souvent appelé simplement « sérialisable » dans les systèmes modernes, par exemple PostgreSQL avec la sérialisable snapshot isolation ou les protocoles à verrouillage strict. Elle ajoute à la sérialisabilité par conflit la contrainte suivante : si T1 précède T2 dans le temps réel, alors T1 doit précéder T2 dans tout ordre sérialisable.

**Nuance importante**

Il faut distinguer deux notions voisines. D'une part, la sérialisabilité par conflit, notion plus faible, ne garantit pas nécessairement le respect du temps réel pour les transactions non chevauchantes. Un graphe de précédence acyclique peut être obtenu sans refléter l'ordre réel de transactions qui ne se chevauchent pas. D'autre part, la sérialisabilité stricte, ou sérialisabilité avec préservation du temps réel, qui est la notion forte, l'exige explicitement. Ainsi, selon la définition retenue, la réponse peut varier : si l'on parle de sérialisabilité au sens fort, celui des systèmes de gestion de bases de données modernes et de la littérature sur les transactions distribuées, la réponse est oui, sans ambiguïté.

**Confiance : 90 %**

Cette confiance reflète le fait que la réponse dépend de la définition précise de « sérialisable » retenue. La distinction entre sérialisabilité par conflit et sérialisabilité avec préservation du temps réel est un point technique bien établi de la littérature, notamment dans les travaux sur les niveaux d'isolation et la sérialisable snapshot isolation, mais la terminologie peut varier selon les auteurs, ce qui justifie de ne pas atteindre une certitude absolue.

Je reste à votre disposition pour approfondir, par exemple sur la différence entre sérialisabilité par conflit et sérialisabilité par vue, ou sur la manière dont les protocoles concrets, comme le verrouillage à deux phases, la validation optimiste ou la snapshot isolation, satisfont ou non cette contrainte de temps réel.