Newsgroup: it.comp.programmare.win32
Titolo: Ritardi dell'ordine di pochi millisecondi??

Sto facendo un programma in VC++ 6.0 sotto Windows 98 SE.
Il mio programma è composto da + processi, vorrei sapere se è possibilie,
secondo voi, realizzare in qualche modo una funzione che blocchi uno di
questi processi, o comunque una parte di codice allinterno, per alcuni
millisecondi. Diciamo dell'ordine di 5-10 millisecondi. In modo da poter
inserire un ritardo, seppur minimo tra un'operazione e l'altra. Ho provato
con la GetLocalTime e con la clock, ma entrambe mi danno un ritardo minimo
di 50-60 millisecondi.
Non è possibilie andare un po' + fine?
Avete idee da darmi o soluzioni da propormi?

Questo mi sembra proprio un lavoro per la Sleep( msec)
Ciao !!

Ciao, Diego!
Il giorno 10/10/2003 alle ore 10:54 hai scritto:
 D> un'operazione e l'altra. Ho provato con la GetLocalTime e con la clock,
 D> ma entrambe mi danno un ritardo minimo di 50-60 millisecondi.
 D> Non è possibilie andare un po' + fine?
In Windows tutte le tempistiche non sono mai garantite.
Comunque c'e' Sleep che richiede il tempo in millisecondi, oppure puoi
attendere un lock che non verra' mai sbloccato con WaitForSingleObject e il
tempo indicato in millisecondi, oppure ancora puoi aumentare la risoluzione
del multimedia timer con timeBeginPeriod/timeEndPeriod e leggere il timer
con timeGetTime. Vedi un po' quella che risulta piu' adeguata.
Bye

 
In windows tutte le funzioni di ritardo ti garantiscono che _come 
minimo_ trascorrerą il numero di millisecondi richiesto.
Se continui a leggere il clock avrai una busy wait (la CPU "schizza" 
al 100% per la durata del loop), meglio usare una Sleep o una  
WaitForSingle/MultipleObject (se la tua attesa puņ essere interrotta 
prima del timeout) ma, anche alzando al massimo la prioritą del tuo 
thread/processo, non avrai intervalli affidabili.
I delay pił precisi sono quelli garantiti dai timer multimediali, ma 
anche questi possono essere ritardati da operazioni di I/O o altre 
attivitą.
Windows 9x e XP/2000 non sono sistemi real-time.
Se ti serve un sistema real-time devi passare a windows CE (che 
garantisce tempi di ritardo precisi al millisecondo per thread ad 
alta prioritą).
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 alta priorità).
Aggiungiamo, se non stai programmando un telefono cellulare: Lascia stare.
Sei troppo preciso Valter ;-)

 
Non ho capito cosa intendi.
Windows CE non serve solo per i cellulari (anzi, in quel segmento di 
mercato ha preso batoste recenti, con produttori che l'hanno 
abbandonato in favore di altre piattaforme).
Se usi un PC con windows 9X o NT/2000/XP "standard" non puoi avere 
tempi di ritardo e tempi di risposta precisi al millisecondo. 
Ci sono estensioni real-time per windows NT e derivati (in pratica un 
sistema operativo che "ospita" windows), estensioni per linux e 
sistemi dedicati al realtime (QNX e altri).
Windows CE è una delle soluzioni possibili.
Ovviamente tutto dipende da quanto è critico il rispetto dei tempi di 
ritardo del nostro amico.
Se un ritardo sbagliato comporta un peggioramento delle prestazioni, 
Diego può accettare questa penalità, magari dedicando 
all'applicazione un PC ultra-potente e customizzato (magari con XP 
embedded) in modo da non avere servizi/applicazioni che 
interferiscano con la sua.
Se provoca un errore nell'applicazione (magari un pezzo da scartare, 
se controlla una macchina industriale) il problema può diventare 
inaccettabile (o, al contrario, essere "sopportato" se si presenta 
molto raramente con gli accorgimenti spiegati sopra e se il costo 
dell'errore è basso).
Se si ripete troppo spesso o se un solo errore può avere conseguenze 
gravi (un componente della sua macchina da qualche migliaio di euro 
si schianta o il pezzo da scartare costa parecchio), allora vale la 
pena di considerare un sistema operativo diverso.
Windows CE può essere una buona soluzione se l'applicazione del 
nostro amico è scritta in C/C++ usando le API, ATL, MFC o comunque 
librerie supportate su CE.
Se l'applicazione è scritta in altri linguaggi o usa librerie non 
portabili su CE o sistemi operativi real-time, allora si possono 
considerare le estensioni real-time (ma ci sarà del lavoro da fare 
per adattare l'applicazione e, probabilmente, delle royalties da 
pagare per ogni copia).


dell'errore è basso).
scusa se mi permetto... ma se servono precisioni simili... non basterebbe
usare un sistema operativo non multitasking? (DOS...)
forse e' una fesseria... nel caso mi piacerebbe sapere perche'...
ciao


Il multitasking č 'fondamentale' nel realtime. Il controllo di sensori,
l'azionamento di piů motori ecc. richiedono sempre un approccio
multitasking, raramente riconducibile alla semplice processazione di eventi.
Attenzione il DOS , ad esempio accede al disco, non č che poi sia cosě
preciso nei ritardi..


Ok, ma un'applicazione windows tipica è una applicazione 'da scrivania', non
necessita di real-time, se te ne accorgi ad applicazione scritta: hai
sbagliato.
Comunque in genere si separa il real-time da resto e via..

 
Credo che la risposta giusta sia "dipende" :)
Se deve fare una e una sola cosa, senza troppa grafica, senza bisogno 
di collegarsi in rete o stampare, supportando un hardware che non 
cambierà mai, allora anche DOS può essere una soluzione valida. 


 
Altra osservazione giusta.
Però, se il real-time non gira con prestazioni accettabili sulla tua 
piattaforma hai due scelte:
- migrare anche il resto
- aggiungere uno strato (hardware o software) che ti consenta di 
gestire il real-time senza riscrivere il resto.
La prima soluzione con CE è abbastanza gestibile. Verso altri sistemi 
l'unica possibilità è che il "resto" fosse scritto in java...
La seconda possibilità prevede un hardware esterno (i microcontrollori 
da 5 euro) interfacciato con il PC (con tutti i problemi del caso, se 
un collegamento seriale non basta!) o uno strato software (estensioni 
real-time).



Sono troppo pigro per aprire un nuovo thread.
Questa è una battaglia già sentita, un programmatore che viene dal mondo
Windows gradirà molto un sistema come CE, uno che viene dai controllori da 5
Euro, cercherà altre soluzioni, la terra di mezzo è tutta da colonizzare,
per questo è nato CE.
Non so da cosa dipenda che alcuni produttori di cellulari abbiano
abbandonato CE per Symbian. Il mio cellulare WinCE della prima ora non mi fa
mancare niente.
Ho valutato CE quando era 2.0 e non era una gran cosa, adesso penso sia più
interessante.
Tu parli a ragione di Java e C#: le applicazioni "grafiche" spesso vengono
spesso sviluppate in Java e, sui telefoni (un bel mercato tipo), questo
rende CE meno interessante. Anche Motorola ( consorzio Symbian) sembra che
abbia abbracciato questa filosofia:
http://www.motorola.com/mediacenter/news/detail/0,1958,2349_1920_23,00.html
Il trucco per l'ambiente poco integrato è quello di rivolgersi a
distribuzioni Linux specializzate per l'embedded, che sono a pagamento e ti
supportano, anche motorola l'ha fatto.
Altri produttori di sistemi operativi embedded hanno cambiato la loro
politica di royalties dopo l'affermazione di linux nel campo che a ricevuto
da questo una spinta notevole.
Non credo nell'affermazione di ATL ecc. Ma forse mi sbaglio.
Non si fosse capito i preferisco il controllorino sull'USB/Seriale ;-)
Ciao !!

 Non si fosse capito i preferisco il controllorino sull'USB/Seriale ;-)
:-)
Per curiosità, cosa fai nell'embedded?
La realtà italiana è spesso nascosta e una maggiore collaborazione
penso gioverebbe a tutti...
Crossposto su it.comp.programmare e metto li il follow-up, che qui
siamo diventati decisamente OT...
ciaociao
-- 
Gerolamo
www.overweb.it

Che ne pensi di scartabellare sui codici macchina, tirare giù il tempo di
clock necessario ad eseguire alcuni comandi assembly,
controllare la frequenza del tuo processore (e la serie del tuo processore)
ed in fine sommare tante istruzioni macchina finchè non totalizzi 10ms.....
dopo chiudi tutto in un codice di sistema nella windows  32... ed in fine
speri che chiamandolo il sistema non salti da un task ad un'altro :-) , ma
questo puoi evitarlo se non erro con due istruzioni che indicano al
processore che non può cambiare task durante l'esecuzione delle istruzioni
che ti totalizzano i tuoi mitici 10ms....
Max

 totalizzi 10ms.....
...e il fatto che il tuo processore non abbia nessuna cache, ovvero di
potere garantire che tutte le istruzioni sono in cache sin dall'inizio,
se no addio previsioni... e che il tuo processore non sia di quelli
per laptop che possono dinamicamente variare ("step") la velocita` di
esecuzione secondo la carica delle batterie... e attento alle pipeline
e diavolerie come i 'lookaside buffer' (piccole cache specializzate
sotto falso nome)...
In breve, a me pare che questo approccio, proponibile su 8086 / 8088 di
una dozzina d'anni fa, sia un poco problematico sulle tipiche CPU di
oggi, piene di meccanismi che paiono proprio studiati per rendere
impossibile la previsione dei tempi d'esecuzione (sono fatti allo scopo
di accelerare statisticamente l'esecuzione quando possibile, ovviamente).
Alex

 che ti totalizzano i tuoi mitici 10ms....
L'unica istruzione che conosco simile a quella che dici e` CLI. :)
In ogni caso si tratterebbe senz'altro di istruzioni privilegiate, che
un processo in user mode non puo` chiamare. Sicuramente ci sono un sacco
di metodi per fregare Windows, ma onestamente non credo che lo sforzo
valga il risultato.
-- 
Lorenzo

 > processore che non puň cambiare task durante l'esecuzione


 e si potrebbe fare un ciclo che calcoli quei mitici 25ms ...
Unix ? Real Time ? Non è che ti confondi ?
Unix non nasce real time, esistono delle estensioni real time per il kernel
linux, che potrebbero risolvere il problema, oppure delle versioni
specializzate, come il menzionato QNX.
In realtà credo che ci siano anche estensione real time per windows da
scrivania ( come le Venturecom). Anche se non ne so molto..
Ciao !!

"Giacomo" <nob...@no.where> ha scritto nel messaggio
news:hILjb.44694$e6.15...@twister2.libero.it...

vero, hai ragione Linux.
Ciao

 Avete idee da darmi o soluzioni da propormi?
Forse  potresti usare  l'istruzione assembly  RDTSC (Read  Data Time
Stamp Counter). Dovrebbe dare in output  (in EAX) il numero di cicli
macchina eseguiti in totale  dall'accensione. Attenzione che i cicli
macchina non sono i millisecondi e variano da un PC all'altro! :-)
Magari scrivi qualcosa tipo...
static inline int RDTSC(){ __asm__ ( db 0x0f, 0x031 ); };
a=RDTSC(); Sleep(55); b=RDTSC(); cxm=(b-a)/55;
...ed  avrai  in  cxm  il  numero di  cicli  CPU  effettuati  in  un
millisecondo!  Un'attesa  di  55  ms   per  la  taratura  penso  sia
"invisibile" per l'utente. Per  attendere y millisecondi si potrebbe
fare qualcosa tipo:
void attendi(int y){int a; a=RTDSC(); while( (RTDSC()-a)*cxm<y ); };
Non ho  compilato nulla e  non so se  possa funzionare una  cosa del
genere, quindi non copritemi di  insulti... :-) Volevo solo dare uno
spunto... :-)
-- 
........This message is best viewed with fixed spaced font..........
 
http://digilander.libero.it/fantoibed
 -=SpP=-

 in real time
UNIX non è real-time nemmeno per finta. Le "estensioni real-time" sono, 
infatti, soltanto funzioni esplicitamente ottimizzate (bloccaggio della 
memoria in RAM, lancio più veloce di eseguibili, allocazione di memoria 
con un allineamento specifico, ecc.) a discapito della portabilità, NON 
vere funzionalità hard real-time. UNIX significa multitasking, sempre e 
comunque
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 allinterno, per alcuni millisecondi
se Sleep non va bene, metti un ciclo vuoto (busy wait). La velocità del 
processore influirà sul numero di ripetizioni necessarie, quindi dovrai 
prima calibrare il ciclo, facendolo girare per qualche migliaio di giri 
e dividendo il tempo trascorso (usa il contatore ad alta risoluzione se 
disponibile - vedi QueryPerformanceFrequency e QueryPerformanceCounter) 
per il numero di giri. Dividi 100 millisecondi per il tempo ottenuto, e 
il risultato sarà il numero di giri che dovrà fare il ciclo


 il risultato sarà il numero di giri che dovrà fare il ciclo
e che se lanci tale tentativo di trovare una buona media di busy ed intanto nel 
sistema stava girando altro di molto pesante ti falsa tutti i valori ...
ciao

 Stamp Counter).
Non importa quanto sia preciso il timer che usi, il problema e` che
tutti i Windows a 32 bit sono OS con multitasking di tipo preemptive. Il
che significa che il tuo loop di controllo puo` essere arbitrariamente
sospeso dallo scheduler e ripristinato diverse decine di millisecondi
dopo.
E` giusto quello che ha detto Valter: in Windows (come in qualsiasi
sistema operativo, ovviamente) puoi avere la certezza che sia passato
*almeno* il tempo che volevi, ma non che sia passato *al massimo* il
tempo che volevi. Quest'ultima e` una peculiarita` dei sistemi realtime.
-- 
Lorenzo

programma tutto sun un microcontrollore, poi collegalo alla seriale ed il
gioco è fatto :-)
MaX

 falsa tutti i valori ... 
se nel sistema gira altro di molto pesante le attese vengono falsate in 
ogni caso. E' lui quello che si vuole impiccare, io suggerisco soltanto 
la corda


 diverse decine di millisecondi dopo.
Ovviamente è così, ma si cerca  di risolvere il sistema nel migliore
dei modi  possibili... RDTSC ha il  vantaggio di contare i  cicli di
CPU _totali_,  cioè sia quelli  eseguiti all'interno del  mio thread
che quelli eseguiti  all'esterno ed è sicuramente più  veloce di una
chiamata ad un'API di sistema!!! :-)
Il mio loop farà 3 giri se la  CPU è molto impegnata, 30 (o 300, non
so,  non ho  fatto conti...)  se  è poco  impegnata... Se  la CPU  è
talmente impegnata che  il mio loop al primo giro  è già in ritardo,
allora più  di tanto  non si  può fare....  E` come  nei videogiochi
quando diventano scattosi... :-)
Ah, ho  sbagliato a dire  che è una variabile  a 32bit! E`  a 64bit,
memorizzata in EDX:EAX, ma per quello che serve ad un programmatore,
basta EAX. C'è da aggiungere un  valore assoluto tra prima e dopo il
conteggio  (basta un  AND logico),  però, altrimenti  si rischia  di
ottenere un "delta" negativo quando EAX passa per lo zero... :-)
Saluti!


 gioco è fatto :-)
Un altro fratello !!