Meccanismi di invio delle code di lavoro

RDBSS usa code di lavoro del kernel Di Windows per inviare operazioni su più thread per un'esecuzione successiva. I driver del mini-reindirizzamento di rete possono usare le code di lavoro gestite da RDBSS per l'invio delle operazioni per un'esecuzione successiva.

RDBSS fornisce diverse routine che implementano il meccanismo di invio usato in SERVIZI Desktop remoto. Queste routine possono essere usate anche dai driver del mini-redirector di rete.

RDBSS tiene traccia degli elementi di lavoro per ogni oggetto dispositivo. Ciò consente a RDBSS di gestire le race condition associate al caricamento e allo scaricamento di mini-reindirizzamentori di rete. Questo fornisce anche un meccanismo in RDBSS per impedire a un singolo mini-redirector di rete di usare in modo ingiusto tutte le risorse.

Esistono alcuni scenari in cui l'invio di elementi di lavoro è inevitabile. Per evitare frequenti allocazioni di memoria e per liberare operazioni in questi scenari, il WORK_QUEUE_ITEM viene allocato come parte di un altro dato. In altri scenari in cui l'invio è raro, è consigliabile evitare l'allocazione di memoria fino a quando non è necessario. L'implementazione della coda di lavoro RDBSS fornisce entrambi questi scenari sotto forma di invio e registrazione di richieste di coda di lavoro. Nel caso dell'invio tramite la routine RxDispatchToWorkerThread , non è necessario allocare memoria per il WORK_QUEUE_ITEM dal chiamante. Per la pubblicazione tramite la routine RxPostToWorkerThread , la memoria per il WORK_QUEUE_ITEM deve essere allocata dal chiamante.

Esistono due casi comuni di invio delle operazioni ai thread di lavoro:

• Per un'operazione molto rara, usare la routine RxDispatchToWorkerThread per conservare l'uso della memoria allocando e liberando in modo dinamico la memoria per l'elemento della coda di lavoro quando necessario.

• Quando un'operazione verrà inviata ripetutamente, usare la routine RxPostToWorkerThread per risparmiare tempo allocando in anticipo il WORK_QUEUE_ITEM come parte della struttura dei dati da inviare.

Il compromesso tra le due operazioni di invio è il tempo rispetto allo spazio (uso della memoria).

Il meccanismo di invio in RDBSS offre più livelli di code di lavoro per ogni processore. Attualmente supportati i livelli seguenti di code di lavoro:

• Critico

• Delayed

• Ipercritico

La distinzione tra Critico e Ritardato è una delle priorità. Il livello HyperCritical è diverso dagli altri due in quanto le routine non devono essere bloccate (attendere qualsiasi risorsa). Questo requisito non può essere applicato, pertanto l'efficacia del meccanismo di invio si basa sulla collaborazione implicita dei clienti.

L'implementazione della coda di lavoro in SERVIZI Desktop remoto è basata su un'implementazione KQUEUE. Il supporto aggiuntivo prevede la regolazione di un certo numero di thread che sono attivamente in attesa degli elementi di lavoro. Ogni struttura di dati della coda di lavoro viene allocata dalla memoria del pool non di paging e ha un proprio meccanismo di sincronizzazione (uno spinlock).

Oltre a prenotare informazioni (ad esempio lo stato e il tipo di coda), RDBSS mantiene anche le statistiche raccolte per tutta la durata della coda di lavoro. In questo modo è possibile fornire informazioni utili per l'ottimizzazione di una coda di lavoro. Numero di elementi elaborati, numero di elementi che devono essere elaborati e strutturata la lunghezza cumulativa della coda. La lunghezza della coda cumulativa è una metrica importante e rappresenta la somma del numero di elementi in attesa di elaborazione ogni volta che è stato accodato un elemento di lavoro aggiuntivo. La lunghezza della coda cumulativa divisa per la somma del numero totale di elementi elaborati e il numero di elementi da elaborare fornisce un'indicazione della lunghezza media della coda. Un valore molto maggiore di uno indica che il numero minimo di thread di lavoro associati alla coda di lavoro può essere aumentato. Un valore molto inferiore a uno indica che il numero massimo di thread di lavoro associati alla coda può essere ridotto.

La coda di lavoro viene in genere avviata in uno stato attivo e continua fino a quando non viene rilevata una situazione non recuperabile (ad esempio, la mancanza di risorse di sistema) o quando passa allo stato inattivo. Quando viene avviato un rundown, passa allo stato di esecuzione in corso.

Il rundown delle code di lavoro non è completo quando i thread sono stati attivati. La terminazione dei thread deve essere garantita prima che le strutture di dati possano essere eliminate. L'implementazione della coda di lavoro in SERVIZI Desktop remoto segue un protocollo in cui ogni thread da attivare salva un riferimento all'oggetto thread nel contesto di rundown. Il thread di rilascio del rundown (che non appartiene alla coda di lavoro) attende il completamento di tutti i thread attivati prima di rimuovere le strutture di dati.

L'implementazione corrente delle code RxDispatchToWorkerThread e RxPostToWorkerThread funziona nello stesso processore da cui ha avuto origine la chiamata.

Le routine RDBSS seguenti per l'invio della coda di lavoro includono.

Ciclo	Descrizione
RxDispatchToWorkerThread	Questa routine richiama una routine nel contesto di un thread di lavoro. La memoria per il WORK_QUEUE_ITEM viene allocata da questa routine.
RxPostToWorkerThread	Questa routine richiama la routine nel contesto di un thread di lavoro. La memoria per il WORK_QUEUE_ITEM deve essere allocata dal chiamante.
RxSpinDownMRxDispatcher	Questa routine rimuove il contesto del dispatcher per un mini-reindirizzamento di rete. Si noti che questa routine è disponibile solo in Windows Server 2003 e Windows XP.