Si, è l'unico problema o, se vuoi, IL problema.Originariamente inviato da misterx
quindi scusa due thread che condividono per definizione la memoria possono accedere uno il scrittura ed uno in lettura senza causare crasch al processo stesso giusto?
Uni problema casomai resta che i due thread potrebbero leggere situazioni non allineate, giusto?
ciao e grazie,Originariamente inviato da oregon
Ok ... allora studia le API che fanno capo a questo argomento
http://msdn.microsoft.com/en-us/library/ms684122(v=VS.85).aspx
conosco le API di windows in quanto le uso già da diverso tempo, mi sono del tutto nuove però le problematiche legate ai thread: sto sviluppando un software real time.
grazie 1000 Dark867, il problema di avere i dati allineati tra i due thread lo avevo risolto con un Mutex ma mi introduce un "grosso" problema: se un thread è costretto ad attendere l'altro allora torno ad avere gli stessi benefici di un processo e quindi l'uso dei thread diventa inutile.Originariamente inviato da Dark867
Si, è l'unico problema o, se vuoi, IL problema.
Non è proprio vero...dipende da come strutturi il codice e se il particolare problema si presta ad essere parallelizzato! (xke c sn anke problemi ke nn riesci a parallelizzare in modo soddisfacente)
Ad es se il processo di generazione del valore da produrre lato produttore e il processo di gestione del dato consumato lato consumatore sono lunghi allora conviene xke, a parte l'ingresso nella zona critica (ovvero la produzione/consumazione), tutte le altre attività possono venir fatte in parallelo!
Tale vantaggio si incrementa ulteriormente se utilizzi più thread, ma dipende tt dal saper scrivere codice concorrente, ke alla fine è un'arte.
beh, io col mutex lo avevo strutturato a questo modo:
//Produttore
Setto_Mutex
Riempio_Array
Rilascio_Mutex
//consumatore
Setto_Mutex
Leggo_Array
Rilascio_Mutex
tale sistema mi era smbrato il più logico ma ho pensato: se lo schduler da retta a produttore e all'interno del mutex scade il suo quanto di tempo, il consumatore rimane in attesa sino a quando il produttore non rilascia il mutex.
A questo punto se la CPU viene assegnata ad una ltro processo esterno dal mio i tempi di attesa del consumatore si allungano e non è prevedibile a priori di quanto.
A questo punto mi sonon chiesto: non è meglio che i due thread viaggino liberamente senza attendersi a vicenda intanto il consumatore continua a mostrare i dati disponibili al tempo t1 e quando ne saranno disponibili al tempo t2 vedrò quelli più aggiornati.
A un esame risolsi un problema simile in questo modo (c'erano xo molti produttori e molti consumatori):
1-usa un altro array di appoggio: questo array potrà assumere solo i valori <dato pronto> <dato assente> <in scrittura>, ogni elemento dell'array ha una corrispondenza 1-1 cn l'array vero e proprio.
2- quando un produttore/consumatore vuole accedere a una locazione dell'array controlla prima l'array di supporto alla ricerca di una cella adatta (nel caso di consumatore <dato pronto>), setta poi il valore della cella(consumatore: <dato letto>) e infine va a prendersi effettivamente il dato.
La risorsa critica su cui imporre il lock diventa quindi l'array di stato e, siccome devi solo verificare/settare un parametro, il lock ha una durata molto breve.
Questa soluzione funziona bn nell'ipotesi ke c siano molti thread e ke la lettura/scrittura prenda tempo (molto maggiore d quello x settare l'array di supporto).
quindi così facendo posso evitare di usare un mutex sempre se non ho capito male.
Difatti il mio problema è che trovo difficile determinare quanto tempo intercorre tra la scrittura e la lettura dell'array e sottrarre questo tempo al tempo reale che voglio calcolare.
Secondo la tua esperienza, se nel momento in cui produttore scrive l'array setto un tempo iniziale t1 iniziale e un tempo t2 finale cioè prima della lettura dell'array da parte di consumatore riesco ad ottenere tempistiche affidabili sempre che mi tengono in considerazione i ritardi tra i due thread?
A questo punto potrei lasciare il mutex che mi garantirebbe che l'array letto da cosnumatore è sempre aggiornato.
grazie
No a entrambe le cose:
1)Il mutex lo usi cmq ma sull'array di appoggio!Questo xke io suppongo ke scrivere in quest'array prenda poco tempo rispetto a scrivere nell'array vero.
2)Puoi ottenere tempistike affidabili se fai una media d tante esecuzioni, ma qst nn t aiuta ad evitare il mutex: lo devi mettere, altrimenti otterrai sempre una race condition, ovvero dati inconstistenti.
Nel mio esercizio la scrittura avveniva sulle righe di un file di testo: siccome il tempo x accedervi era di molti ordini d grandezza + lento del tempo x accedere sull'array di supporto (ke ovviamente era in memoria)il mio prog girava molto veloce.
Senza sapere ke fa la tua applicazione è difficile dirti se convenga o no usare la concorrenza, in generale conviene se i 2 thread girano quasi sempre in parallelo tranne ke x l'accesso alla risorsa critica (magari x prendere decisioni), oppure, nel caso di un array, se è possibile scrivere/leggere in + celle contemporaneamente.
scusa ma avere dati inconsistenti non significa che i due thread si trovano a scrivere/leggere nel medesimo sitante con conseguente blocco del processo vero?
Sono tutte problematiche che devo scrivere
Quello che sto scrivendo è un programma real time che deve leggere 1024 byte da una scheda e devo visualizzare ogni quanto tempo cambiano di stato i suoi singoli bit.
Per tale propostio ho allestito due thread con mutex ma per via dei ritardi introdotti dallo scheduler di windows che non riesco a quantificare mi era venuta l'idea di dimenticarmi del mutex e lasciare i due thread ciclare liberamente per essendo cosciente dell'inconsistenza dei dati.
Però avevo il dubbio che accedendo entrambi alla medesima locazione il processo si sarebbe bloccato ma tu mi informi che quello che può accadere è solo inconsistenza
grazie 1000
Allora, facciamo ordine: il fatto ke un programma blokki/crashi/faccia-saltare-in-aria-il-pc dipende dal programma e non ha niente a ke fare cn l'inconsistenza dei dati, ke in generale genera errori! (dato inconsistente: non puoi prevedere il suo valore xke varia da esecuzione a esecuzione a causa della concorrenza incontrollata)
Esempio 1:
-il dato nella tua zona critica rappresenta un indirizzo di memoria.
Senza controllo di concorrenza può succedere ke i 2 thread scrivano una cosa inconsistente, ke potrebbe (potrebbe!) risultare un indirizzo d memoria esterno al programma, risultato--> il programma crasha, xkè è andato in segmentation fault!
Esempio 2:
-il dato nella tua zona critica rappresenta un valore da sommare ad un altro o da visualizzare a video.
Verrà sommata/stampata una cosa senza senso, tipo ke 2+2 fa 1 --> l'utente penserà ke il programma non funziona bene.
Esempio 3:
-il dato deve andare in un file di configurazione del sistema operativo.
In quel file verrà scritta una cosa senza senso --> il sistema operativo non si avvierà più o potrebbero verificarsi crash di sistema!
Come vedi sono tutti comportamenti ke nn vuoi, ma a seconda del programma possono portare a consequenze diverse, da una cosa fastidiosa a una cosa gravissima!
Il tuo problema può essere parallelizzato usando cm risorsa critica un buffer in cui il thread produttore inserirà di volta in volta i 1024 byte da leggere e il thread consumatore li prenderà.
Conviene xke il thread produttore impiega tempo x accedere in memoria (addirittura in una periferica esterna), mentre in thread consumatore impiega tempo xke deve comparare dei byte, quindi mentre il primo thread va in memoria a prendere altra roba il secondo nel frattempo può iniziare il confronto.
Puoi ottenere forse un po' d velocità in + se usi + thread alla volta x piccole porzioni di byte.
Permessi di invio
Rispondi quotando