Quando si progetta una coda di lavoro, che cosa dovrebbe determinare l'ambito di un lavoro?

Quale di questi rappresenta l'aggiunta utile minima al lavoro che fa l'applicazione? Di solito considero che un lavoro in coda dovrebbe rappresentare un'unità di lavoro utile: se completa o annulla, dovresti finire con il sistema in uno stato coerente.

Questa situazione è per lo più definita dal tuo dominio problematico, quindi non è qualcosa per cui esiste una risposta generale. A volte ci sono dei limiti architettonici che ti costringono a suddividere il lavoro in modi innaturali. Un esempio è in un'applicazione GUI, in cui probabilmente si mira a eseguire contemporaneamente tutte le attività dell'applicazione, ma si aggiorna l'interfaccia utente su un thread dedicato. Ciò significa che devi dividere il tuo lavoro ("fai qualcosa di utile e mostra all'utente che l'ho fatto") in questi due passaggi ("fai qualcosa di utile e mostra all'utente che l'ho fatto"). In questo caso, infatti, non è un problema, perché se l'app si chiude prima di aggiornare l'interfaccia utente è probabile che l'utente non volesse sapere del lavoro che hai svolto comunque.

Se "l'aggiunta utile minima" è troppo piccola, penso a ridurli per ridurre la quantità di tempo speso nel sovraccarico di sottomissione del lavoro. Questa definizione di "troppo piccolo" è qualcosa che richiede misurazione per il tuo lavoro e nel tuo ambiente - dipende più dall'architettura che dal tuo problema. Profili la tua applicazione: se impieghi una notevole quantità di tempo nell'aggiunta e rimozione di elementi dalle code o nella creazione e distruzione di thread, stai facendo troppo poco lavoro in ogni operazione.

Prima di tutto: perché queste attività Fetch e Invia sono combinate comunque?

Se dipendono l'uno dall'altro (utilizzare i dati dell'altro o devono essere elaborati in un determinato ordine), il "Lavoro" dovrebbe essere atomico, essere conservato ed elaborato insieme all'interno del nodo.

D'altra parte, se "Job" è la rappresentazione di un'unità di comunicazione sul lato del destinatario (come quando i nodi raccolgono le attività in entrata e in uscita in code verso l'altro nodo e le scaricano regolarmente), allora è solo un secchio di compiti indipendenti che ora contengono due elementi. In questo caso dovresti suddividere il "Job" (e rinominarlo in Envelope :-)) e registrare le attività singolarmente nella coda dei lavori.

L'ottimizzazione delle prestazioni per la gestione delle code può attendere fino a problemi reali. In un ambiente di elaborazione della coda parallela, avere un core che lavora su un grosso lavoro mentre gli altri core sono in stand-by è meno efficiente (e più difficile da scalare) rispetto al sovraccarico relativamente ridotto di più gestione delle code.

Dal mio punto di vista, suddividere un lavoro potrebbe essere un'opzione migliore. Sì, aggiunge complessità, ma ha anche i suoi vantaggi. Se si dispone di un sistema di elaborazione della coda, in un determinato momento si avranno più lavori in coda che richiedono una pianificazione per prestazioni migliori.

I singoli sistemi di lavoro di solito hanno tempi di attesa più lunghi per i processi che arrivano più tardi in coda. Potrebbe anche essere necessario dare priorità ad alcuni lavori rispetto ad altri (pianificazione delle priorità). In breve, la pianificazione è efficiente se un lavoro ha sottostanti. Come hai detto, ha anche un modello di recupero migliore e gli stati possono essere facilmente manipolati.