Lorsque le verrou en écriture est rétrogradé, le thread qui a actuellement acquis le verrou en écriture doit maintenir le verrou en écriture, puis acquérir le verrou en lecture, puis libérer le verrou en écriture.
Alors pourquoi est-il nécessaire de maintenir le verrou en écriture ? ?
L'image ci-dessus mentionne "Alors le thread actuel ne peut pas détecter la mise à jour des données du thread T". Comment comprendre cela. Si le thread T acquiert le verrou en écriture puis met à jour les données, le thread actuel ne peut pas percevoir la mise à jour des données avant que le verrou en écriture ne soit libéré. Ce n'est pas un problème, mais une fois que le thread T a libéré le verrou en écriture, le thread actuel peut sentir le problème. mise à jour des données. Cela ne devrait poser aucun problème à comprendre ici, n'est-ce pas ?
aidez-moi à expliquer, merci
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Cela explique le déclassement du verrouillage. Premièrement, le verrou en écriture est exclusif, le verrou en lecture est partagé, puis les verrous de lecture et d'écriture s'excluent mutuellement entre les threads. Le principe du déclassement du verrouillage est que tous les threads veulent être sensibles aux données. changements, mais à cause de l'écriture, il n'y a qu'un seul verrou, donc une dégradation se produira.
Si vous libérez d'abord le verrou en écriture, puis acquérez le verrou en lecture, d'autres threads peuvent acquérir le verrou en écriture avant de l'acquérir, bloquant l'acquisition du verrou en lecture, et vous ne pourrez pas détecter les modifications des données. Par conséquent, vous devez d'abord maintenir le verrou en écriture pour vous assurer que les données ne changent pas, acquérir le verrou en lecture, puis libérer le verrou en écriture.
Les verrous en écriture n'autorisent pas les opérations de lecture et d'écriture à partir d'autres processus, tandis que les verrous en lecture autorisent les opérations de lecture.
D'après l'exemple que vous avez capturé, lorsque vous relâchez le verrou en écriture, le processus T acquiert le verrou en écriture. À ce stade, vous ne pouvez pas acquérir le verrou en lecture, vous devez donc d'abord acquérir le verrou en lecture, puis libérer le verrou en écriture.
Tout d’abord, vous ne comprenez pas la signification du verrou en lecture-écriture. L’existence d’un verrou en lecture signifie que les autres opérations d’écriture ne sont pas autorisées.
Selon l'exemple que vous avez fourni, il peut y avoir un thread de transaction qui ne souhaite pas que son opération soit interrompue par d'autres threads, et cette opération de transaction peut être divisée en plusieurs parties pour mettre à jour différentes données (ou tables) ou même être très longue -consommant. Si le verrou en écriture est utilisé exclusivement pendant une longue période, il n'est évidemment pas autorisé pour certaines applications à réponse élevée, donc après avoir terminé certaines opérations d'écriture, le verrou en lecture est utilisé pour rétrograder afin de permettre une réponse aux opérations de lecture d'autres processus. Le verrou n'est libéré que lorsque toutes les transactions sont terminées.
Selon votre compréhension, si le verrou en écriture est occupé par d'autres threads, alors le thread de transaction devra s'interrompre et attendre que d'autres verrous en écriture soient libérés.
"Alors le fil de discussion actuel ne peut pas percevoir la mise à jour des données du fil T"
Lorsque T1 lit les données, la valeur des données est copiée dans le contexte du thread actuel, de sorte que les autres threads n'ont aucun moyen de détecter si les données ont été mises à jour. Tant que les données sont soumises à la mémoire, c'est-à-dire au tas, les autres threads peuvent obtenir la dernière valeur.