Progetto firefly3SYNC | LINK AL PROGETTO

Requisiti

Realizzazione di un simulatore di un sistema (denominato firefly3SYNC) costituito da 3 lucciole. Il comportamento deve evolvere in due fasi:
  1. Primi 10 secondi: lampeggio a frequenza costante propria (asincrono).
  2. Successivamente: lampeggio in maniera sincrona.
È richiesta la definizione di un modello QAK che simuli accuratamente il ciclo di vita e la sincronizzazione degli attori.

Analisi dei Requisiti

Analisi del Problema

Architettura del Sistema

Il sistema è logicamente diviso in due contesti distribuiti:

Il problema della sincronizzazione

Se ogni lucciola utilizzasse un timer locale (es. whenTime), piccole differenze di scheduling del sistema operativo causerebbero sfasamenti che si accumulano nel tempo. Il core problem è che non esiste un meccanismo intrinseco negli attori indipendenti per rimettersi in fase.

Decisione Analitica: Per garantire la sincronia perfetta, è necessario passare da un modello a "timer distribuiti" a un modello a "clock centralizzato".

Progetto

Il Coordinator come Direttore d'Orchestra

La scelta progettuale chiave è l'introduzione di un unico attore centralizzato, il coordinator, che scandisce il tempo tramite Eventi Broadcast.

QActor coordinator context ctxfirefly {
    State s0 initial {
        delay 10000 // 10 secondi di fase asincrona iniziale
    }
    Goto loop

    State loop {
        emit sync : sync(1) // Segnale simultaneo per tutti
        delay 1500
    }
    Goto loop
}

Firefly: Attori Puramente Reattivi

Le lucciole vengono modellate come entità prive di stato temporale proprio nella fase di regime, rendendole dipendenti dal segnale sync.

State wait_sync { }
Transition t0 whenEvent sync -> flash

State flash {
    forward griddisplay -m cellstate : cellstate($X, $Y, 1)
    delay 500
    forward griddisplay -m cellstate : cellstate($X, $Y, 0)
}
Goto wait_sync

Vantaggi della soluzione