[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [linux] [OT] Programmation: petites questions...
Salut, si j'ai bien compris tu as un thread qui remplit le buffer msgrcv et
un autre qui le lit et cela en concurrence...
Ton usleep t'évite ces désagréments, mais ce n'est toujours pas la bonne
méthode.
Tu réduits juste les risques que ton thread lise les données en même temps
que l'autre les écrit.
Il vaut mieux utiliser des sémaphores (man semaphore).
Le mieux est de créer deux fonctions: remplir_buffer() et
consommer_buffer().
Tu as un sémaphore commun aux 2 threads, appelons le buffSem.
remplir_buffer() {
sema_wait(bufSem);
if ((nbreBytesRecus = recv(handler, msgrcv+totrecu,
TAILLEMSGMAX, 0)) == -1) {
/* rendre le sémaphore */
sema_post(bufSem);
DD("Rien recu... \n"," ");
perror("pas de reception\n");
return NULL;
}
else {
/* rendre le sémaphore */
sema_post(bufSem);
sprintf(tg,"%d",nbreBytesRecus);
DD("nbreBytesRecus : %s\n",tg);
usleep(100000);
fflush(NULL);
totrecu += nbreBytesRecus;
}
Tu places donc remplir_buffer() dans ta boucle.
Dans l'autre thread, dans chaque cycle tu appelles la fonction
consommer_buffer(buffer_local) et tu travailles sur buffer_local, sans
risque qu'il soit corrompu au fur et à mesure de la lecture.
consommer_buffer(char *copie_buffer){
sema_wait(semBuf);
memcpy(copie_buffer, msgrcv, totrecu);
sema_post(semBuf);
}
En espérant que ça te dépanne.
Christophe
> -----Original Message-----
> From: Benoit Joseph [mailto:benoit.joseph@teledisnet.be]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Salut,
>
> Je dois programmer un proxy cache pour mes études, tout se passe bien
> Juste une ou deux petites questions...
>
> 1) Y a -t-il moyen de rendre les opérations sur la mémoire synchrones?
> Parce que je dois jouer avec des zones mémoires "assez grandes" ou
> faire des realloc (puisque je ne sais pas a priori la taille de ce que
> je reçois...). Le problème est que je suis obligé de mettre un usleep
> pour freiner le processus sinon, quand je boucle, je reviens sur le
> recv() et les opérations mémoires sont corrompues... (même si je vire
> le realloc). C'est sans doute une bêtise mais je ne la vois pas. Je
> précise que je programme en multithread et donc que ce code peut
> tourner un nombre indéterminé de fois en même temps
>
> voici le code incriminé:
>
> do {
> if ((nbreBytesRecus = recv(handler, msgrcv+totrecu,
> TAILLEMSGMAX, 0)) == -1) {
> DD("Rien recu... \n"," ");
> perror("pas de reception\n");
> return NULL;
> }
> else {
> sprintf(tg,"%d",nbreBytesRecus);
> DD("nbreBytesRecus : %s\n",tg);
>
> usleep(100000);
> fflush(NULL);
> totrecu += nbreBytesRecus;
>
> }
> }while (nbreBytesRecus != 0 && nbreBytesRecus == TAILLEMSGMAX &&
> nbreBytesRecus != -1);
>
> Voilà c'est l'essentiel...
>
> Si quelqu'un a une solution..
>
> D'avance merci
>
> Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8A24yLPnuiaZn1q4RAinsAJ0eRyn0ko8Cmp14JassPrz68rhweQCfZcKI
> hxHmN95enTkANjPy26algqE=
> =Mjne
> -----END PGP SIGNATURE-----
>
> [ Soyez précis dans vos sujets svp afin de déterminer directement ]
> [ le type de demande... ]
> [ Pour vous (dés)inscrire, aller sur http://unixtech.be/ml.php ]
> [ Archives de la mailing list: http://archives.unixtech.be/linux/ ]
> [ http://unixtech.be Contact: listmaster@unixtech.be ]
>
[ Soyez précis dans vos sujets svp afin de déterminer directement ]
[ le type de demande... ]
[ Pour vous (dés)inscrire, aller sur http://unixtech.be/ml.php ]
[ Archives de la mailing list: http://archives.unixtech.be/linux/ ]
[ http://unixtech.be Contact: listmaster@unixtech.be ]