Newsgroup: it.comp.programmare
Titolo: Dubbio su thread e mutex

Se ho una funzione lockabile che ritorna un valore, come questa:
 
 
int WriteSome(char *b, int len)
{
pthread_mutex_lock(P);
 
// ecc. ecc...
 
pthread_mutex_unlock(P);
return retval;
}
 
posso fidarmi che non ci saranno guai sul return finale? Non ï¿œ che per 
caso mi conviene riscriverla cosï¿œ:
 
void WriteSome(char *b, int len, int *retval)
{
pthread_mutex_lock(P);
 
// ecc. ecc...
 
pthread_mutex_unlock(P);
}
 
 
opinioni?

 opinioni?
 
La seconda ;)
Ciao!


 
Mi stra-associo... per il poco che vale
 
BTW, nella documentazione di SQLite da qualche parte c'è
la citazione "il mulithread è il male [o il diavolo]" e ho
avuto modo di rendermene conto nel mio piccolo.
 


Per SQLite forse, e vorrei sapere perché (magari non tutte le funzioni della libreria di SQLite sono threadsafe, per cui bisogna vedere ad ogni chiamata quali lo sono e quali no, ma questo succede spesso usando anche altre librerie).
In generale il multithreading a volte è l'unica soluzione *decente* a disposizione.
Personalmente poi non capisco perché c'è l'idea generale che il multithreading sia una cosa difficile: a volte è complesso (nel senso che bisogna prendere in considerazione varie cose) ma normalmente è abbastanza banale.
Ciao!

 banale.
 
A me diverte, peraltro, e lo uso volentieri anche quando non
sarebbe necessario. Quello che trovo complicato è il
debug, perché io non sono un programmatore professionista
con tutte le conseguenze del caso.
 
ciao!
 
Apx.
 

 Personalmente poi non capisco perché c'è l'idea generale che il multithreading sia una cosa difficile: a volte è complesso (nel senso che bisogna prendere in considerazione varie cose) ma normalmente è abbastanza banale.
 
Io ci sto avendo a che fare ora per la prima volta, e a parte il dubbio 
esposto ho dovuto rendermi conto che alcune cose vanno proprio fatte in 
modo diverso. Le code di messaggi diventano una necessità vitale. Non 
puoi dare return nel bel mezzo di una funzione ma devi trascinarti il 
valore di ritorno fino alla fine del codice.
Il resto ve lo dico man mano che lo scopro :-)
 
Se non fai così, ti ritrovi con un programma che funziona una volta sì e 
una no. E per il mio, anche se sto attento a scansare tutte le trappole 
che riesco a vedere, non sono mica sicuro che alla fine funzionerà tutte 
le volte che lo lancio. Prevedo molte e lunghe sedute di debugging...
 

 le volte che lo lancio. Prevedo molte e lunghe sedute di debugging...
 
Mah, guarda, secondo me le linee guida da seguire in realtà son poche..
- ogni dato condiviso deve avere un mutex
- ogni funzione prima di far qualcosa deve controllare se può procedere o meno, poi lock, e quando ha finito unlock (di quel che è, mutex, semafori, monitor, etc.)
- se gestisci più di un mutex/semaforo/spinlock/etc. questi vanno sempre presi nello stesso ordine e rilasciati nell'ordine opposto (altrimenti potresti andare in deadlock)
- pensare "esagerato": i processori sono tantissimi, il tempo di ogni thread è molto diverso tra uno e l'altro, etc. Questo aiuta a non cadere in trappole stupide.
 
E, aggiungo, ma questo è un po' più ad alto livello, e vale solo per le performances:
- (quasi) mai aspettare un thread in un altro thread
- usare algoritmi thread-friendly!
 
Sicuramente ce ne sono molte altre ma, a meno che non mi sia scordato qualcosa, direi che sono più che abbastanza! ;)
Ciao!

 Puoi anche fare return in mezzo, basta che liberi i lock! ;)
 
S�, poi fai qualche modifica e misteriosamente gli unlock finiscono 
sempre dove non dovevano stare... pi� sicuro farlo una volta sola alla 
fine della funzione :-)