Producer e più consumatori con elementi di tipo limitato

1

Sto implementando produttore-consumatore dove gli articoli da consumare sono di 1000 tipi type-0, type-1, ..., type-999.

Il produttore inserisce la voce di tipo -i in coda. Consumatore utilizza quello per aggiornare la macchina di stato per tipo-i (una macchina a stati per tipo-i) in base all'elemento (tipo-i) rimosso dalla coda. Ci sono più utenti che stanno leggendo dalla stessa coda (e un produttore)

La condizione è che se un consumatore sta elaborando un articolo di tipo-i, altri consumatori non possono elaborare un articolo dello stesso tipo, quindi se altri consumatori prelevano i prossimi articoli dello stesso tipo-i, tutti i consumatori vengono bloccati e non è una buona soluzione. / p>

Un'altra soluzione è avere 1000 code e 1000 consumatori per ogni tipo-i che non è fattibile

Un'altra soluzione è di avere 10 code e 10 consumatori (uno per ogni coda) e assegnare 100 tipi a Q-1, 100 tipi a Q2 ecc. Ma il problema è se il consumatore-j impiega molto tempo per elaborare item-i tutti gli altri elementi in coda subiranno un ritardo sebbene l'altro consumer-k potrebbe essere inattivo.

Qual è il buon modello di progettazione che possiamo usare qui?

UPDATE:

Soluzione 1: (1 coda - 1 consumatore) per tipo: soluzione migliore ma molti thread

Soluzione 2: (1 Queue - m Consumatori) per n tipi: problema potremmo raggiungere lo stato in cui tutti i consumatori sono in attesa di elaborazione di tipo i mentre il primo utente continua a lavorare su tipo-i tenendo il blocco (tipo-i )

UPDATE 2:

Qui l'ordine degli articoli è IMP e non può essere modificato. È possibile assumere una macchina a stati per tipo-i e il consumatore modifica lo stato in base al nuovo elemento (di tipo-i) ricevuto. Ora puoi capire perché l'ordine degli articoli è importante

    
posta sameer 02.08.2016 - 14:25
fonte

1 risposta

1

In primo luogo, voglio confermare che ho capito bene il problema. Hai N tipi diversi di articoli in una coda principale e N consumatori, ognuno dei quali è responsabile esattamente di un tipo di articoli. Un consumatore responsabile dell'elaborazione di articoli di tipo X non può elaborare articoli di tipo Y. Tutto ciò che segue è basato su questa ipotesi.

Forse puoi organizzare i tuoi consumatori in una collezione e fare un round robin sbirciando in coda. Ogni consumatore dovrebbe dare un'occhiata al prossimo elemento in coda per verificare se è l'oggetto da elaborare. In tal caso, il consumatore preleva l'articolo dalla coda e avvia l'elaborazione, rilasciando così la coda per altri processori.

Questo approccio ridurrebbe il reciproco blocco dei consumatori a meno che non ci siano molti elementi dello stesso tipo in una sequenza nella coda principale. In tal caso, altri consumatori dovrebbero attendere fino a quando il consumatore in questione non elabora tutti gli articoli. Per evitare questo problema, è possibile inserire una coda in ciascun utente, in modo che il consumatore che trova il tipo appropriato nella coda principale lo inserisca nella propria coda e lo elabori in un thread separato. Questa soluzione si tradurrebbe in tanti thread quanti sono i consumatori, ma se si utilizza il meccanismo semaforico in ciascun consumatore, si potrebbe ridurre quell'effetto negativo, poiché non tutti i thread sarebbero attivi contemporaneamente.

Se il numero di thread è troppo grande, puoi sempre ricorrere al raggruppamento di tipi, come suggerito. In tal caso, potresti apportare qualche ritocco assegnando i tipi che appaiono più spesso nella coda principale a diversi utenti, in modo da sfruttare al meglio il parallelismo del lavoro. Ovviamente, se i tipi sono distribuiti uniformemente, non è possibile utilizzare questo approccio.

    
risposta data 02.08.2016 - 15:22
fonte

Leggi altre domande sui tag