Exercice 1
1e point
Non, car writeLock()
garantit qu’un seul rédacteur peut écrire à la fois.
2e point
Oui, car readLock()
permet à plusieurs threads lecteurs d’accéder en même temps
à la ressource.
3e point
Non, un rédacteur bloque tous les lecteurs et autres rédacteurs lorsqu’il écrit.
4e point
Le thread lecteur[0] est interrompu avec ce message: lecteur 0 0 0
interompu 0 et le programme ne s’arrête pas.
5e point
Directement dans le code avec la function run()
:
Nous modifions Lect
et Red
en utilisant finally
pour s’assurer que les
verrous sont toujours libérés.
Exercice 2
Exclusion entre rédacteurs
Non, car TropSimple
utilise le même ReentrantLock
pour lecture et écriture.
Plusieurs rédacteurs peuvent écrire en même temps.
Entre lecteurs et rédacteurs
Non, car readLock()
et writeLock()
retournent le même verrou, permettant
potentiellement un accès simultané.
Plusieurs lecteurs peuvent-ils lire en même temps ?
Non, TropSimple
ne différencie pas lecture et écriture, donc un seul thread
peut accéder à la base à la fois.
Exercice 3
1e point
A-t-on l’exclusion entre rédacteurs ?
Oui, car lockW()
s’assure qu’un seul rédacteur écrit à la fois.
A-t-on l’exclusion entre lecteurs et rédacteurs ?
Oui, lockW()
attend que tous les lecteurs aient terminé avant d’accorder
l’accès à un rédacteur.
Plusieurs lecteurs peuvent-ils lire en même temps ?
Oui, tant qu’aucun rédacteur n’écrit, plusieurs lecteurs peuvent acquérir
le verrou.
2e point
A
passera-t-il avant B
?
Non, B pourrait être servi avant A si d’autres lecteurs continuent à lire, causant une famine des rédacteurs.
Rédacteur n’a jamais accès à la base ?
Oui, si de nouveaux lecteurs arrivent en continu, un rédacteur peut être bloqué indéfiniment.
3e point
On modifie lockR()
pour empêcher de nouveaux lecteurs d’entrer si un rédacteur attend.