Version imprimable
Bonjour,
Voilà je me pose une question simple :
Je dispose d'une application multi-threads. J'ai un certain nombre de sockets ouvertes, mais je voudrais savoir d'il est possible pour 2 threads d'émettre et de recevoir sur la même socket en même temps ?
Autrement dit, je dois utiliser un mutex par socket, ou bien 2 (un pour la réception, un pour l'émission) ?
Merci d'avance...
La premiere chose à faire serait de faire un petit programme test qui essaie de communiquer sur un socket à travers deux threads differents.
Normalement, il ne doit pas y avoir de probleme.
En fait la question c'est "est ce que le socket est un object thread safe" D'après les quelques traces que j'ai vues sur différents forum, il semble que oui mais je ne sait pas (je n'ai pas trouvé :?) ce que dit Microsoft dans le MSDN
Ce n'est pas facile de faire un programme qui PROUVE extérieurement qu'un objet est thread safe ou qu'il ne l'est pas. Seule la doc de l'objet peut le dire.Citation:
Envoyé par darrylsite
Petite précision, dans mon cas il s'agit de sockets bluetooth (stack microsoft). Mais a priori les sockets ont un niveau d'abstraction suffisant pour qu'on se moque du protocole... non ?
Du coup il est aussi possible qu'il n'y ait besoin d'aucun mutex, même si plusieurs threads sont bloqués en réception sur la même socket ??
Sinon mes recherches google n'ont pas donné grand-chose... avant que je n'utilise les mots-clés "socket thread safe", effectivement. Bien vu. Je continue les recherches et je donne mes résultats !
Je dirais ouiCitation:
Envoyé par madmox
C'est possible mais cela me pose un problème.Citation:
Envoyé par madmox
Si plusieurs thread sont en attente de lecture sur un socket et qu'il arrive quelquechose à lire, je ne sais pas quel thread va être débloqué. Peut être même que tous les thread seront débloqués , un seul aura quelque chose à lire et les autres auront 0 octets à lire. C'est dommage de débloquer des thread pour ne rien faire. et en plus quel intérêt d'avoir plusieurs thread en attente de réception sur un socket ?
Un socket permet a deux entités de communiquer avec un respect de l'ordre dans lequel sont transmis et recus les messages.Citation:
Envoyé par madmox
Je ne pense pas qu'il y ait une mécanique qui empêche deux threads d'utiliser la même socket. Par contre, tout l'intérêt de la socket est perdu:
- thread 1 : envoi un message et attend une réponse
- thread 2 : attend un message
thread2 recevra autre chose que le message attendu et thread1 ne recevra pas sa réponse.
On peut complexifer en mettant dans des en-tête de message le numéro de thread correspondant mais associer une socket à chaque threads me parait beaucoup plus simple.
Un socket est un objet système et l'OS sérialise déjà les opérations sur cet objet, est-il utile d'en rajouter?Citation:
Autrement dit, je dois utiliser un mutex par socket, ou bien 2 (un pour la réception, un pour l'émission) ?
- W
Certes, ce n'est pas très malin, c'était juste pour l'exemple...Citation:
quel intérêt d'avoir plusieurs thread en attente de réception sur un socket ?
Ca me pose un problème : le nombre de sockets ouvrables en bluetooth est fortement limité... quelque chose comme 2 ou 3 sous Windows CE 5.0, environnement que j'utilise pour mon application.Citation:
associer une socket à chaque threads me parait beaucoup plus simple
J'utiliserai donc une seule socket par client. Le mécanisme de mon application fait qu'un thread est en attente de message et envoie une réponse quand il reçoit une demande, et un autre se charge d'envoyer des mises à jour. Il ne devrait donc pas y avoir besoin de synchronisation...
A mon sens, les questions de synchronisation ne portent pas sur la "socket" mais sur les échanges entre les 'entités' qui, a chaque extrémité, vont l'utiliser pour dialoguer.Citation:
Envoyé par madmox
-W