Discussion :

[psykoboy]

Bonsoir a tous,

J'utilise un thread pour recevoir des messages UDP que je stocke dans une liste chainée. Tout se passe bien. Voici le code :
PS : Les threads utilisés sont les threads windows (CreateThread...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
struct timeval tv;  
tv.tv_sec = 0;		//timeout in seconds
tv.tv_usec = 100; //timeout in micorseconds
Message_Struct * myMessage = (Message_Struct*)malloc(sizeof(Message_Struct));
while ( stopRequired == 0 ) {		
                FD_ZERO(&readfs);		
		FD_SET(mySocket, &readfs);
		if(select(mySocket + 1,&readfs,NULL,NULL,&tv)){
                        // Error check
                }
		// Check if there is available data 
		if(FD_ISSET(mySocket,&readfs)){ // Utilisation des descripteur non nécessaire puisque thread uniquement pour la récetpion
			// Copy them
			byteLength = recvfrom(mySocket, (char*)myMessage, sizeof(Message_Struct),0,(SOCKADDR*)&fromAddress,&fromAddressLength);       
			if(byteLength > 0){
				// Get the linked list node where to store it
				msg = getMessageStorage(myMessage->Signature);				
				if(msg != 0){				 
					memcpy(msg,myMessage,sizeof(Message_Struct));						
				}			
			}
		}
    }

J'ai 2-3 questions :
- pourriez vous me confirmer que l'utilisation de descripteur ici ne sert a rien, puisque le thread est uniquement créé pour récupérer les messages recu, et les stocker dans une liste chainée ? Qu'en est il de la charge du processeur ? J'ai besoin que ce thread soit aussi léger que possible.

- Je voudrais remplacer memcpy par un echange de pointeur pour gagner en vitesse. En échangeant le pointeur du message recu myMessage dans le recvfrom avec celui de la liste chaînée. Du genre, remplacer le memcpy par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
LinkedListNode* tmpNode = getListNode(myMessage->Signature);
if(tmpNode != NULL){
	Message_Struct  * tmpMsg = tmpNode->Message;
	tmpNode->Message = consumedExchange;
	myMessage = tmpMsg;
}

-Cela presenterai t-il réellement un gain de vitesse ? (Je pense que oui, l'interversion de pointeur me semblant plus rapide que le memcpy)
-Cela peut il présenter d'autres dangers ? Le message recu n'est accédé qu'en lecture...

Merci

[gangsoleil]

Bonjour,

Je tiens tout d'abord a te faire remarquer que tu ne testes pas le code de retour de malloc, et que tu accedes a myMessage ensuite. Si l'allocation memoire est refusee, ton programme va lamentablement se vautrer.

Sinon, concernant le memcpy, les deux comportements que tu cites ne sont pas identiques :
MEMCPY : tu as le meme contenu dans les espaces memoires pointes par msg et par myMessage
Copie de pointeurs : tu auras plusieurs pointeurs qui pointent la meme zone memoire.

La reponse depend donc de ce que tu souhaites faire.

[psykoboy]

C'est vrai que je ne fait pas la vérif du malloc. Dans quels cas un malloc peut-il être refusé ?

En fait je ne veux pas faire de la copie de pointeur, mais bien intervertir 2 pointeurs. Ce qui fait que mes 2 pointeurs désigneront bien des zones mémoires distinctes et que la zone d'écriture du recvfrom change entre chaque appel. Elle sera la même, si la signature du message reçue est la même.

Quoiqu'il en soit je ne sais pas si le gain de vitesse sera phénoménal.

Je suis en train de faire des tests de vitesse sur mon thread de réception.
Je donnerais plus d'infos une fois que j'aurais des éléments clairs.

[gangsoleil]

Bonjour,

Pour malloc, le cas le plus courant est lorsque le systeme refuse de t'allouer de la memoire car il n'y en a plus de disponible. Mais ce n'est pas la seule raison.

Pour ce qui concerne la vitesse d'execution, cela va dependre du volume de donnees copie : s'il est gros, alors oui, tu as un gain evident a faire un echange de tes pointeurs.
En revanche, si l'espace memoire a copier est petit, le gain, meme s'il est reel, risque d'etre negligeable.

Si tu es en phase d'optimisation, n'oublie pas la regle suivante : on passe 80% du temps d'execution dans 20% du code.

Donc il vaut mieux optimiser ces 20% que le reste : le gain sera bien meilleur.