[C/C++] Teorema del campionamento

[!fazz]

Originariamente inviato da misterx

ciao,
siccome ho scritto un programma che in definitiva è un campionatore, mi chiedevo se il teorema del campionamento è usabile anche nel mio caso.

Ho un thread che scansiona le porte di un apparato collegato via ethernet e riempe un array di 1024 byte.

Un secondo thread verifica se qualcuno dei suoi bit ha cambiato di stato: mi interessano i singoli bit, se a zero oppure ad uno.

Un terzo thread resta in attesa del secondo e se c'è qualcosa da scrivere su disco viene risvegliato.

Ho notato che i tempi di esecuzione tra i vari thread in windows XP sono dell'ordine di 1/3 millisecondi e quindi del tutto trascurabili per i miei scopi.

La domanda: se il dispositivo più veloce cambia il suo stato ogni 500 millisecondi ed io eseguo il primo thread ogni 250 millisecondi è garantito che riesco a catturare in modo preciso lo stato di tutti i bit dell'apparato?

E' un dubbio un pò forse banalotto ma non avendo esperienza vi chiedo conferme soprattutto in quanto ho verificato che lo scheduler di windows XP è veramente NON deterministico.

grazie 1000

nessun programma su xp ti assicurerà quello che chiedi in quanto il s.o. non è realtime

[misterx]

Originariamente inviato da starfred

La parola sempre è un po' azzardata. Come si può intendere sempre?
1 minuto? 1 ora? 1 giorno? E' troppo relativo. Questo tipo di programmazione deve essere corretto dal punto di vista teorico.
Bisogna sempre ricondursi al worst case (che prima o poi si verificherà) e gestire il sistema di conseguenza.
Prova ad immaginare un sistema con 3 thread che eseguono questa operazione per 1000 volte:
TH1: Sleep(10); signal(TH2); wait();
TH2: Sleep(10); signal(TH3); wait();
TH3: Sleep(10); signal(TH1); wait();

Segnati l'orario di inizio e fine rimarrai molto sorpreso dal risultato

purtoppo non ho esperienza in programmazione di questo tipo
Ma come faccio a questo punto a capire se il tempo che leggo è quello di variazione del bit oppure dei vari sleep?

[misterx]

grossolanamente il codice è questo

byte buf[1024];
//TH1
while(1)
{
      WaitForSingleObject(hMutex,INFINITE);

      RiempiArray(buf);

      ReleaseMutex(hMutex);

     Sleep(250);
}

//TH2
while(1)
{
      WaitForSingleObject(hMutex,INFINITE);
      
      for(int i=0; i<1024; i++)
      {
             if(bit cambia stato)
             calcola_tempo();

             SetEvent ( hEvent2 );

      }
      ReleaseMutex(hMutex);

     Sleep(50);
}

//TH3
while(1)
{
            WaitForSingleObject(hEvent2 ,INFINITE);
      
             Salva_Tempo();

             ResetEvent( hEvent2 );


}

[misterx]

Originariamente inviato da !fazz

nessun programma su xp ti assicurerà quello che chiedi in quanto il s.o. non è realtime

ma non si riescono nemmeno a quantificare i ritardi introdotti da xp ?

[starfred]

Mi spiace ma non conosco il funzionamento di quelle funzioni quindi non ti saprei dire cose corrette; come mai hai scelto di utilizzare le MSDN Library?

Non puoi quantificare i ritardi per una valanga di motivi tra cui: non conosci il numero di processi, non conosci i tempi dei singoli processi, non conosci le deadline dei processi, non conosci lo scheduler, non conosci la priorità dei processi... etc. etc.

[misterx]

Originariamente inviato da starfred

Mi spiace ma non conosco il funzionamento di quelle funzioni quindi non ti saprei dire cose corrette; come mai hai scelto di utilizzare le MSDN Library?

Non puoi quantificare i ritardi per una valanga di motivi tra cui: non conosci il numero di processi, non conosci i tempi dei singoli processi, non conosci le deadline dei processi, non conosci lo scheduler, non conosci la priorità dei processi... etc. etc.

ok, grazie 1000 a tutti

Sto facendo alcune prove e noto ritardi di al massimo 15 millisecondi tra una lettura l'altra.
I dati reali mi sono stati forniti dal costruttore del dispositivo e dove viene dichiarato 1 secondo io leggo a volte 1,015 = 1015 ms

[!fazz]

Originariamente inviato da misterx

ma non si riescono nemmeno a quantificare i ritardi introdotti da xp ?

spannometricamente oltre 1s di tempo ciclo l'influenza del sistema operativo diventa trascurabile

[misterx]

Originariamente inviato da !fazz

spannometricamente oltre 1s di tempo ciclo l'influenza del sistema operativo diventa trascurabile

forse anche 0.5 s ???

Ho notato una certa ripetibilità dopo centinaia di migliaia di misurazioni vie ethernet dove il massimo ritardo che ho registrato sono 15 ms che guarda caso sembrano proprio quelli che inserisco io come pausa tra i thread.

[starfred]

Prova a stressare di tanto la macchina e poi effettua il test. Che tempi ci sono?

[marco.r]

Originariamente inviato da misterx

nella mia situazione ho un thread che legge dati da ethernet e riempie un array di 1024 byte ogni tot millisecondi, questo perchè io non posso sapere quando cambia lo stato dei bit dell'apparato; questo è un compito che spetta al mio programma come spetta anche calcolare per quanto tempo è rimasto a zero oppure a uno ognuno dei suoi bit.

Ma l'apparato manda lui i dati ogni tot millisecondi oppure sei tu che ogni tot fai uan richiesta sulla rete e ottieni risposta ?

Siccome non so ogni quanto cambiano di stato i tali bit, ecco l'esigenza di uno sleep che liberasse la CPU per altri programmi, altrimenti avrei un uso della CPU pari al 100%

In ogni caso se il problema e' quello dell'occupazione della cpu, avrebbe molto piu' senso che il secondo thread rimanga in attesa e venga risvegliato solo quando almeno uno dei 1024 byte viene cambiato (il confronto non dovrebbe occupare molto tempo).
Tieni inoltre presente che se tu fai una sleep di 500 ms, l'esecuzione non avviene ogni mezzo secondo, perche' ci devi aggiungere anche il tempo di esecuzione tra una sleep e l'altra. Dovresti schedulare una sleep di (500 - tempo appena consumato) (oppure una schedulazione ricorrente, se il sistema operativo lo supporta).

[misterx]

Originariamente inviato da starfred

Prova a stressare di tanto la macchina e poi effettua il test. Che tempi ci sono?

provo a lanciare 5 processi uguali

[marco.r]

Originariamente inviato da misterx

La domanda: se il dispositivo più veloce cambia il suo stato ogni 500 millisecondi ed io eseguo il primo thread ogni 250 millisecondi è garantito che riesco a catturare in modo preciso lo stato di tutti i bit dell'apparato?

Si', ma te ne accorgi con un ritardo che puo' anche arrivare a 250 ms (perche' se e' cambiato giusto appena dopo che eri entrato nella sleep.)

E' un dubbio un pò forse banalotto ma non avendo esperienza vi chiedo conferme soprattutto in quanto ho verificato che lo scheduler di windows XP è veramente NON deterministico.

Tieni presente il discorso che ho fatto sopra sulla durata della sleep. Per come l'hai impostato, il tuo ciclo non ha durata 250 ms, ma 250+X con X il tempo di esecuzione del codice del loop. La cosa peggiora ancora di piu' se per qualche motivo il ciclo viene messo in pausa per qualche motivo nel mezzo della sua esecuzione.

[starfred]

Io intendo una situazione di sovraccarico; hai presente quando il mouse si muove a scatti?
Prova a fare il test mentre usi un programma di stress pesante della cpu e I/O

[misterx]

una volta che si è assestato il programma in quanto allo start i tempi sono randomici, il ritardo che leggo è +/- 16 millisecondi

[misterx]

Originariamente inviato da marco.r

Ma l'apparato manda lui i dati ogni tot millisecondi oppure sei tu che ogni tot fai uan richiesta sulla rete e ottieni risposta ?

In ogni caso se il problema e' quello dell'occupazione della cpu, avrebbe molto piu' senso che il secondo thread rimanga in attesa e venga risvegliato solo quando almeno uno dei 1024 byte viene cambiato (il confronto non dovrebbe occupare molto tempo).
Tieni inoltre presente che se tu fai una sleep di 500 ms, l'esecuzione non avviene ogni mezzo secondo, perche' ci devi aggiungere anche il tempo di esecuzione tra una sleep e l'altra. Dovresti schedulare una sleep di (500 - tempo appena consumato) (oppure una schedulazione ricorrente, se il sistema operativo lo supporta).

sono io che impongo il tempo di lettura per non sovraccaricare la CPU.

Ho provato anche ad implementare due CreateEvent() in modo che il TH1 risvegliasse TH2 quando questo ha finito di leggere da ethernet ma nulla vieta poi a TH1 se non metto un semaforo, di fare una nuova lettura da ethernet rendendo i dati nel buffer analizzato in quel momento da TH2 inconsistenti.

[misterx]

Originariamente inviato da starfred

Io intendo una situazione di sovraccarico; hai presente quando il mouse si muove a scatti?
Prova a fare il test mentre usi un programma di stress pesante della cpu e I/O

lancio un rendering

[marco.r]

Originariamente inviato da misterx

sono io che impongo il tempo di lettura per non sovraccaricare la CPU.

Ho provato anche ad implementare due CreateEvent() in modo che il TH1 risvegliasse TH2 quando questo ha finito di leggere da ethernet ma nulla vieta poi a TH1 se non metto un semaforo, di fare una nuova lettura da ethernet rendendo i dati nel buffer analizzato in quel momento da TH2 inconsistenti.

Intendevo dire, visto che gia' usi un mutex per regolare l'accesso, potresti fare si' che sia il primo thread a fare il confronto e rilasci il mutex solo se e' cambiato qualcosa
a questo punto il secondo thread viene eseguito solo quando serve.

[gugoXX]

Originariamente inviato da misterx

sono io che impongo il tempo di lettura per non sovraccaricare la CPU.

Ho provato anche ad implementare due CreateEvent() in modo che il TH1 risvegliasse TH2 quando questo ha finito di leggere da ethernet ma nulla vieta poi a TH1 se non metto un semaforo, di fare una nuova lettura da ethernet rendendo i dati nel buffer analizzato in quel momento da TH2 inconsistenti.

E fagli scrivere da un'altra parte...
Tieni una coda di serie di letture.
Il thread che legge accoda una serie nuova e un riferimento utile per capire quando la lettura e' avvenuta, un semplice sequenziale. Quando e' 42, singifichera' che la serie si riferisce al 42*512ms = 21 secondi dalla partenza, (fatti salve le inaccuratezze di schedulazione fin qui esposte)
Il thread che processa i dati scoda e analizza, con molta calma, quando piu' gli fa comodo.
In questo modo non hai neppure bisogno di mutex se non per accodare-scodare, cosa comunque molto light e gia' anche implementata gratis se usi una System.Collections.Concurrent.ConcorrentQueue<T>

[misterx]

Originariamente inviato da marco.r

Intendevo dire, visto che gia' usi un mutex per regolare l'accesso, potresti fare si' che sia il primo thread a fare il confronto e rilasci il mutex solo se e' cambiato qualcosa
a questo punto il secondo thread viene eseguito solo quando serve.

ma il primo riempie un buffer e non può sapere a priori se è cambiato qualcosa. Solo il secondo se ne accorge ed in questo caso se è cambiato qualcosa è il secondo che risveglia il terzo attraverso un evento in modo che scriva su disco il tempo calcolato.

Tra primo e secondo cè un semaforo per evitare inconsistenza di dati nel buffer e tra il secondo ed il terzo un evento che sempre il terzo, una volta sodisfatto resetta.

[misterx]

Originariamente inviato da gugoXX

E fagli scrivere da un'altra parte...
Tieni una coda di serie di letture.
Il tread che legge accoda una serie nuova e un riferimento utile per capire quando la lettura e' avvenuta, un semplice sequenziale. Quando e' 42, singifichera' che la serie si riferisce al 42*512ms = 21 secondi dalla partenza, (fatti salve le inaccuratezze di schedulazione fin qui esposte)
Il thread che processa i dati scoda e analizza, con molta calma, quando piu' gli fa comodo.

ma per come è costruita la funzione di lettura, io passo un puntatore ad un buffer e questa lo riempie ed ogni volta il ciclo si ripete allo stesso modo ogni tot millisecondi da me imposti.

Non mi viene in mente come accodare

ho allegato il simulatore che si basa sul medesimo principio: è per Borland Builder C++ ma facilemnet adattabile