The Dragon protocol is a snoopy coherence protocol from Xerox PARC (1984) that takes a fundamentally different approach from MSI, MESI, and MOESI: instead of invalidating other caches' copies on a write, it updates them. Every write to a shared line is broadcast on the bus, and every other cache holding that line updates its own copy in place rather than throwing it away.
Invalidate-based protocols bet that a cache that just had its copy invalidated probably won't need it again soon, so throwing the copy away and re-fetching later is fine. Update-based protocols bet the opposite: a cache that was recently sharing a line is likely to read it again soon, so it's cheaper to keep it valid via a broadcast update than to force a full reload later.
Invalidate (MESI-family): write -> other caches drop their copy -> reload on next access Update (Dragon): write -> other caches' copies are refreshed in place
Which bet pays off depends entirely on the access pattern. A line that's read by many cores but written by only one occasionally (a shared, mostly-read configuration value) favors updates, since the readers stay valid without ever missing. A line that's passed exclusively between cores (a lock variable, a work queue head) favors invalidation, since update broadcasts would be pure waste on a line no one else is actually reading anymore.
Because Dragon never invalidates on a write to a shared line, it needs states that distinguish “shared and clean,” “shared and dirty,” and “exclusive” more finely than MESI does, without ever transitioning through Invalid the way MESI's write-to-Shared path does. This adds implementation complexity relative to invalidate protocols, which combined with the update traffic cost on write-heavy-but-rarely-reread lines is a large part of why invalidate-based protocols (MESI and its descendants) became the mainstream choice in general-purpose CPUs, while update-based protocols stayed comparatively niche.