Interfacciando dei threads su una finestra tramite un timer che richiama le funzioni per accedere ai dati condivisi, ho notato che se l’ opzione WakeEarly settata su false, la finestra principale ed i relativi controlli diventano meno reattivi.
A cosa dovuto ci ?
Se viene rallentato il thread principale, vuol dire che anche gli altri threads in esecuzioni vengono rallentati ?
Avendo il thread principale sempre attivo, il thread con l’ opzione Wake Early attivata attender sempre il tempo impostato ?
Che utilit pu avere questa opzione ?
I thread vengono eseguiti uno alla volta, nel senso che occupano uno slot di tempo ciascuno. Con l’opzione weakEarly=true un thread pu (ma dipende da cosa fai) andare in competizione di slot con il thread principale (dove c’ l’interfaccia)
Se impostata a False (default) il thread attender esattamente (nei limiti) il tempo previsto, altrimenti se gli altri non fanno nulla potrebbe prendere lo slot disponibile e ripartire prima.
Nel caso di collegamenti con la UI questo potrebbe crearti (potenzialmente) i problemi di rallentamento dei controlli.
In genere non la uso.
Siccome lo scopo principale della funzione sleep quello di non utilizzare il processore al 100% (del core utilizzato), inserisco nel codice del thread il comando sleep (weakEarly=true) alla fine del ciclo di loop.
Ho notato che impostando anche un valore basso 1 - 2 ms il processore viene utilizzato sotto l’ 1%. (0.2 - 0.5 %).
Da queste prove deduco che il tempo impostato nella funzione sleep (weakEarly=true) influisce poco o nulla sul carico del processore. ( cos ?)
I time slots dei threads sono a livello di applicazione o di sistema operativo ?
Sono gestiti da uno scheduler interno (che puoi influenzare tramite priority)