Ho un'applicazione di acquisizione dati in esecuzione su Windows 7, utilizzando VC2010 in C++. Un thread è un heartbeat che invia una modifica ogni 0,2 secondi per mantenere in vita un hardware che ha un timeout di circa 9 secondi. In genere la chiamata del battito cardiaco richiede 10-20 ms e il thread trascorre il resto del tempo dormendo.Posso impostare la priorità di un singolo thread sopra 15 per un normale processo con priorità?
Occasionalmente, tuttavia, ci sarà un ritardo di 1-2 secondi e l'hardware si spegnerà momentaneamente. Il thread heartbeat è in esecuzione a THREAD_PRIORITY_TIME_CRITICAL che è 15 per un processo con priorità normale. I miei altri thread sono in esecuzione con priorità normale, anche se utilizzo una DLL per controllare un altro hardware e ho notato con Process Explorer che avvia diversi thread eseguiti al livello 15.
Non riesco a rintracciare la fonte del lento verso il basso ma altri nella mia applicazione stanno vedendo lo stesso tipo di ritardi quando ciò accade. Ho apportato diverse ottimizzazioni al codice heartbeat anche se è abbastanza semplice, ma i guasti occasionali si verificano ancora. Ora mi chiedo se posso aumentare la priorità di questo thread oltre i 15 senza specificare REALTIME_PRIORITY_CLASS per l'intero processo. In caso contrario, ci sono dei lati negativi che dovrei sapere di usare REALTIME_PRIORITY_CLASS? (Oltre a questo thread heartbeat, il resto dell'applicazione non ha necessità temporali in tempo reale.)
(Oppure qualcuno ha qualche idea su come rintracciare questi rallentamenti ... non è sicuro se la fonte potrebbe essere nella mia app o da qualche altra parte nel sistema).
Update: Quindi non avevo effettivamente provato il passaggio 31 nella mia chiamata AfxBeginThread e risulta ignora tale valore e imposta il filo alla normalità la priorità al posto dei 15 che ottengo con THREAD_PRIORITY_TIME_CRITICAL.
Aggiornamento: risulta che l'esecuzione dell'utilità di deframmentazione dischi è un buon metodo per causare numerosi ritardi dei thread. Anche l'esecuzione del processo su REALTIME_PRIORITY_CLASS e il thread heartbeat su THREAD_PRIORITY_TIME_CRITICAL (livello 31) non sembrano essere d'aiuto. La prossima cosa da provare è chiamare AvSetMmThreadCharacteristics ("Pro Audio")
Aggiornamento: programmare il thread heartbeat come "Pro Audio" funziona per aumentare la priorità del thread oltre 15 (Base = 1, Dynamic = 24) ma non lo fa sembrano fare davvero la differenza quando la deframmentazione è in esecuzione. Sono stato in grado di correlare molti dei rallentamenti con l'utilità di deframmentazione del disco in modo da disattivare la scansione settimanale. Non riesco ancora a spiegare alcuni ritardi, quindi aumenteremo fino a un timeout del watchdog di 5-10 secondi.
mi fa paura quando le persone usano parole come "battito cardiaco" e "chiuso per motivi di sicurezza" in una questione di programmazione su Windows . :) Non è certamente un RTOS: http://en.wikipedia.org/wiki/Real-time_operating_system – HostileFork
Penso che il tuo cane da guardia sia severo. Su un RTOS i 500 ms sono molti, ma su Windows qualsiasi cosa al di sotto dei 15 secondi è rischioso. Se hai il controllo sul tuo cane da guardia allora ti suggerisco di prolungare il timeout o farlo spegnere solo se manca un certo numero di trigger. – Fozi
Domanda: Qual è il tempo dopo il quale l'hardware si spegne? – Fozi