Commenti esame 21 gennaio Clicca QUI per vedere il messaggio nel forum |
Supernick |
Beh dai, l'esercizio di programmazione mi è sembrato abbastanza fattibile se paragonato a quello degli appelli dell'estate scorsa (client/server, boundbuffer) |
Melodiaz |
ma sinceramente questo era uguale a uno di settembre 09...e secondo me era tra i piu' impestati...sara' che io a programmare nn sono proprio in grado...pero' boh |
Melodiaz |
come ti e' andata? |
LiJay |
secondo me la cosa più difficile era capire la consegna..ho capito a grandi linee cosa fare negli ultimi 20 minuti :D
comunque sia era uguale ad un appello del 2009,sapete dove posso trovarli?sul suo sito mi rimanda sul ccdi
Grazie
edit:trovato http://www.dsy.it/forum/showthread....&threadid=40573 |
matt |
ok, ho un dubbio sulla correzione della parte di C di questo appello
nella funzione dotprod(void *arg), si fa mutex (lock/unlock) solo quando si va a scrivere in prodval.
E tutto il resto? li non può esserci conflitto?
Per esempio, non è possibile che un thread scriva nella variabile "inizio"
un altro thread nella variabile "fine" e un altro thread ancora esegua il ciclo for con le variabili "inizio" e "fine" di sezioni che non dovrebbe calcolare lui?!?!?
cosi a vista direi che è sbagliato.... cosa non capisco?
[edit]
mhh, ho provato a eseguirlo, ed effettivamente fa i calcoli giusti.
comincia a sballare se dichiariamo le variabili "inizio" e "fine" fuori dal metodo, finche sono dentro sono locali e non globali quindi.
E' uscito fuori un altro dubbio però:
fa i calcoli giusti anche togliendo il lock e l'unlock prima e dopo la sezione critica ....
non mi sembra un caso, l'ho eseguito più volte.
idee?!
[fine edit]
[re-edit]
ok, senza il controllo mutex (lock/unlock), comincia a sballare i conti a ogni esecuzione se cominciamo a mettere un valore di lunghezza vettore più alto, per esempio
#define LUNGVET 400000
sotto questo valore, tipo il 400 dell'esercizio, non capisco se per caso o cosa, non accade mai un conflitto [fine re-edit]
|
|
|
|