Coerenza dei diamanti in un sistema concorrente

Nell'industria aerospaziale esiste un formato di file chiamato IRIG 106 Capitolo 10. Utilizza una metafora di pacchetto a più canali. Uno dei canali contiene pacchetti Time, che vengono utilizzati come referente.

Una delle caratteristiche interessanti del Capitolo 10 è che (simile al TCP / IP), i pacchetti possono arrivare in qualsiasi ordine. Ci sono numeri di sequenza nei pacchetti in modo che tu possa riassemblarli nell'ordine corretto, ma se stai cercando di bloccare il tempo e un pacchetto orario non arriva nel flusso di dati quando te lo aspetti, devi bufferizza i dati e attendi finché non arriva.

Per evitare il problema dei pacchetti temporali che semplicemente non esistono, la Specifica Capitolo 10 stabilisce che il ritardo tra il tempo che un pacchetto di tempo rappresenta e il momento in cui viene scritto nel file Capitolo 10 non può superare un secondo. Ciò consente alle apparecchiature di elaborazione dati che elaborano i file Capitolo 10 di progettare i propri sistemi in modo tale da dover solo bufferizzare un massimo di 1 secondo di dati, rimanendo comunque conformi allo standard. Richiede inoltre che i registratori di dati debbano essere progettati per non scrivere mai un pacchetto di tempo dopo più di 1 secondo dopo che è scaduto.

Sembra che tu abbia bisogno di una sorta di vincolo di progettazione simile a questo nel tuo sistema e un modo per gestire la sua non conformità.

Il modo più naturale e concorrente per gestire questo tipo di modello è creare code in entrata e in uscita sia su B che su D e due code in entrata su A (ed eventualmente una coda in uscita su A a seconda di come utilizza il risultato).

Un modo semplice per garantire la limitazione consiste nell'impostare una lunghezza massima della coda in uscita su B e C e sospenderli se la loro coda in uscita supera il valore configurato. Il valore 1 è una coda banale ma in situazioni più complesse il tempo di esecuzione di ogni calcolo può variare o essere difficile da prevedere.

Quindi può avere senso (per esempio) C fare la coda di alcuni risultati mentre B esegue un lungo calcolo nel caso in cui C riceva in seguito un caso complesso mentre a B vengono assegnate piccole attività.

Quindi al suo punto più semplice A guarda una coda, se trova qualcosa guarda l'altro attende su quella coda. Quando ha qualcosa guarda l'altra coda e aspetta lì. Quando ha qualcosa in entrambe le code procede.

Un modo per indirizzare i ritardi "gross" (definiti dal tempo o possibilmente essere n messaggi da una parte o dall'altra) è per A scartare le voci in una delle code e avvisare l'altro processore di saltare in avanti. Ciò comporterà un po 'di risincronizzazione tra le code.

Questo tipo di approccio può essere valido ed è un po 'simile al drop dei frame in un'animazione.

È necessario un modo per "sincronizzare la perdita" dei pacchetti. Nel peggiore dei casi, B potrebbe perdere ogni pacchetto pari, mentre C perde ogni pacchetto dispari, e quindi A non sarà mai in grado di produrre un risultato.

Lasciatemi descrivere il concetto di tale sincronizzazione in un semplice esempio. Quando A ha prodotto il suo messaggio, non lo ha ancora inviato. Invece, lo memorizza in un campo. Solo dopo che sia B che C hanno detto a D che sono pronti a ricevere un nuovo messaggio, D invierà questo messaggio archiviato a B e C . Dopo che B e C hanno terminato il loro compito, A ha un paio di dati corrispondenti allo stesso messaggio originale da D .

Se A genera un nuovo messaggio prima che il messaggio memorizzato sia stato inviato, quel messaggio precedentemente memorizzato viene sovrascritto e quindi perso. Un altro vincolo è che i destinatari del messaggio B e C devono registrarsi con D , e anche informare D che sono pronti, cioè è richiesto un accoppiamento più stretto.

Ovviamente, il concetto di memoria intermedia può essere refactored in una classe a sé stante, in modo che D invii immediatamente il messaggio all'intermediario, che a sua volta lo invierà a B e C quando appropriato.