Come si forma un Intertangle
Due sottosistemi nascono come moduli indipendenti. Col tempo, ciascuno accumula un campo su un god-object condiviso: una struct di configurazione globale, un manager singleton, una classe statica. Ogni aggiunta è corretta se isolata. L’accoppiamento è invisibile nei test su piccola scala.
Tre substrati in cui questo si è calcificato:
VLC media player. Audio, video e playlist condividono un singolo lock che protegge lo stato globale del player. Una richiesta di salto a un timestamp acquisisce il lock, modifica la posizione di riproduzione e svuota il buffer audio. Il sottosistema video, in attesa dello stesso lock, si blocca. Il sottosistema playlist, anch’esso in attesa, non può precaricare. Risultato: tre sottosistemi indipendenti serializzati attraverso un singolo oggetto di stato. Costo prestazionale: contesa del lock O(N) dove N = numero di sottosistemi, tutto proporzionale alla latenza dell’operazione.
Event loop di Redis. Il fsync di AOF (scrittura su disco), la replica (scrittura di rete) e l’esecuzione dei comandi (CPU) condividono l’event loop single-threaded. Ognuno: corretto se isolato. Un fsync lento blocca l’esecuzione dei comandi. Il ritardo di replica peggiora sotto carico di scrittura. Il punto di accoppiamento: un unico contesto di esecuzione condiviso da operazioni con profili di latenza diversi.
VersionSet di LevelDB. Il percorso di scrittura (flush della memtable) e la compattazione in background condividono il lock del VersionSet. Un job di compattazione trattiene il lock per decine di millisecondi. Il percorso di scrittura si blocca. Entrambe le operazioni: necessarie. L’accoppiamento: strutturale, non temporale.
La distinzione critica
Un Intertangle ha un accoppiamento strutturale, non un problema di temporizzazione. Una race condition: due thread accedono a uno stato condiviso senza sincronizzazione. Soluzione: aggiungere un mutex.
Un Intertangle: due sottosistemi condividono lo stato per progettazione. Aggiungere un mutex non risolve l’accoppiamento; serializza l’accesso. I sottosistemi continuano a condividere lo stato. Il collo di bottiglia si stringe.
Aggiungere un mutex a un Intertangle VLC lo peggiora: ora audio, video e playlist attendono tutti un singolo lock. La soluzione strutturale: dare a ogni sottosistema il proprio stato. Phase snapshot: congelare uno snapshot dello stato condiviso al confine di fase, permettere a ogni sottosistema di leggere lo snapshot in modo indipendente, unire le scritture alla fine.
Strutturale vs Temporizzazione
La domanda diagnostica chiave per un Intertangle: aggiungere un mutex lo risolverebbe o lo peggiorerebbe?
Una race condition: l'aggiunta di un mutex la risolve. Un ordinamento corretto degli accessi elimina la corruzione.
Un Intertangle: l'aggiunta di un mutex serializza l'accesso ma preserva l'accoppiamento strutturale. I sottosistemi continuano a condividere lo stato. Sotto carico, continuano a bloccarsi a vicenda. Il collo di bottiglia si restringe.
Come Trovare un Intertangle
Tre segnali di rilevamento:
1. Campi mutabili condivisi tra sottosistemi. Un god-object con campi letti e scritti da più di un sottosistema. Se rimuovere l'accesso a un campo da parte di un sottosistema rompe un altro sottosistema, condividono stato.
2. Singolo mutex che protegge operazioni non correlate. Un lock che protegge il flush audio E la decodifica video E il fetch della playlist: tre sottosistemi con profili di latenza diversi, tutti in attesa l'uno dell'altro. Il segnale: operazioni non correlate sotto lo stesso nome di lock.
3. Regressione delle prestazioni quando si aggiunge carico. La latenza per l'operazione A aumenta quando l'operazione B viene eseguita contemporaneamente, anche se A e B sembrano indipendenti. Non sono indipendenti: condividono stato.
La correzione Phase-Snapshot
Pattern phase snapshot:
# PRIMA: i sottosistemi leggono e scrivono direttamente lo stato condiviso
class GameWorld:
position = {} # stato mutabile condiviso
velocity = {} # stato mutabile condiviso
def physics_tick(world):
for entity in world.entities:
world.position[entity] += world.velocity[entity] # scrive lo stato condiviso durante il ciclo# DOPO: snapshot congelato prima della fase; le scritture vanno nel buffer next_state
def physics_tick(world):
snapshot = world.freeze() # vista immutabile
next_state = {}
for entity in snapshot.entities:
next_state[entity] = snapshot.position[entity] + snapshot.velocity[entity]
world.merge(next_state) # merge atomico al confine della faseOgni sottosistema legge lo snapshot. Nessun sottosistema scrive su di esso. Le scritture si accumulano in un buffer e vengono unite atomicamente al confine di fase. I sottosistemi ora vengono eseguiti in modo indipendente: nessun contenzioso sui lock, nessuna dipendenza di ordinamento, nessun accoppiamento nascosto.
Applica la correzione
Un team segnala un difetto: il sistema di animazione e il sistema di collisione del loro motore di gioco scrivono entrambi su un oggetto di trasformazione condiviso. Quando entrambi vengono eseguiti nello stesso tick, i risultati della collisione dipendono dal fatto che l'animazione sia stata eseguita per prima. L'aggiunta di un mutex ha risolto l'ordinamento, ma ora l'animazione si blocca ogni volta che la collisione esegue una scansione broad-phase.