Discourse verwendet DistributedMutex, eine Implementierung von Redis-Locks für verschiedene Zwecke. Es scheint, dass diese Redis-Lock-Implementierung Timeouts aufweist, wodurch sie eher eine “Lease” als ein “Lock” ist.
Es könnten potenzielle Probleme wie Race Conditions auftreten, wenn das Redis-Lock abläuft, bevor die durch das Redis-Lock geschützte Arbeit abgeschlossen ist.
Das ist richtig, aber wir versuchen, Dinge so zu gestalten, dass sie deutlich weniger Zeit in Anspruch nehmen als das Timeout der Sperre.
Ohne irgendeine Art von Timeout könnten wir in eine Situation geraten, in der der Mutex für immer gesperrt bleibt (z. B. wenn ein Anwendungsprozess die Verbindung zu Redis verliert, während er die Sperre hält).