deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 2016
-
14 nov. 2007 à 19:01
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 2016
-
15 nov. 2007 à 18:52
Yop à tous,
Voila j'ai un prog avec un serveur multi thread et tous ces threads doivent tous modifier ou consulter une listebox dans le programme principale. Donc obligation de synchroniser les thread sinon bordel total en cas d'accès simultanés. Et comme ils ne peuvent y acceder que 1 à la fois, je pense créer un mutex via la fonction CreateMutex.
Cependant , lorsque je regarde dans la msdn, plusieur petite question me viennent à l'esprit.
- le 1 argument, il est mis : If this parameter is NULL, the handle cannot be inherited by child processes . Vu que je vai créer le mutex dans le prog principal (qui sera donc le processus principal), si je met ce paramètre à NULL, est-ce que mes threads pourronts tt de mm avoir acces au mutex. Je dirait oui car les thread ne sont pas vraiment des processus fils à l'application , c'est pas comme si je faisait un fork() (sous linux, je connait pas la fonction sous win mdr).
et deuxième question :
-
<dt>bInitialOwner</dt><dd>If this value is TRUE and the caller created the mutex, the calling thread obtains initial ownership of the mutex object. Otherwise, the calling thread does not obtain ownership of the mutex. To determine if the caller created the mutex, see the Return Values section.
</dd>Sincèrement , je ne comprend pas très bien sont utilité, soit mon anglais est très mauvais ou alors ... Si j'ai bien compris si ce paramètre est vrai alors si on est dans le cas ou la création se fait dans un thread, c'est le thread qui l'à crée qui en à l'acces le 1er ? ce qui serait logique. Mais qu'en est-il si le mutex est crée dans le processus principal ?
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 20162 14 nov. 2007 à 19:49
Ok, grace à monsieur Richter j'ai la réponse à la question 2 . Petites explications pour celui que cela intéressent. En gros bInitialOwner sert à déterminer l'état du mutex à la création. Si ce paramètre est FALSE (cas habituel d'après monsieur Richter :D ) le thread ID (disons pour simplifier l'état du mutex. Thread ID car l'état du mutex se détermine suivant le handle du thread qui obtien l'acces si j'ai bien compris) sera à 0 donc et donc le mutex signalé* (donc accessible), tandis que à TRUE le mutex est non-signalé (un thread est en cours d'éxécution avec l'acces au mutex.
* Signalé = en gros libre. Un thread signalé veut dire un thread qui à fini de s'éxécuté.
non-signalé = en gors pas libre. Un thread non signalé est un thread en cours d'éxécution.
Voila j'espère que que mes explications seront comprise.
cs_rt15
Messages postés3874Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention 7 novembre 201413 15 nov. 2007 à 13:04
Salut,
Pour ta question 1, effectivement, tu n'en as pas besoin vu que ton mutex n'est utilisé que par des threads.
Il faudrait remplir ça si tu voulais faire des CreateProcess avec
bInheritHandle = True et utiliser la même valeur de handle dans le
processus fils (Il faudrait d'ailleurs transmettre cette valeur
manuellement). Pus d'infos ici.
<hr size="2" width="100%" />3ème année en ecole d'ingé d'info cherche stage de 4 mois à partir du 01/04/08
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 20162 14 nov. 2007 à 19:21
Mmmm oui effectivement il y à l'aire d'y avoir ce qui faut, mais bon c'est bcp d'anglais tt ça lol . Mais allait , on va tanter :D . Mais bon c'est questions reste quand mm d'actualité hein :p car je pense pas que je trouverai la réponse tt de suite lol.
cs_aardman
Messages postés1905Date d'inscriptionmercredi 22 janvier 2003StatutMembreDernière intervention17 septembre 20123 15 nov. 2007 à 04:53
Salut,
Déja, si c'est de la synchronisation entre les threads, il vaut mieux
utiliser les critical sections, c'est plus simple et plus rapide.
Ensuite, tout les messages que tu send/post a ta listbox seront traités
par le thread qui a créé cette listbox et non pas par les threads qui
appelent SendMessage ou PostMessage, ils seront donc traités de maniere
sequentielle. Donc pas besoin de synchronisation pour faire ca.
Vous n’avez pas trouvé la réponse que vous recherchez ?
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 20162 15 nov. 2007 à 18:03
Yop,
Aardman , en fait ma listebox est crée bien sur au message WM_CREATE de mon programme principal ( le serveur) et le handle de ce control est déclaré en global pour que tt les threads que je vais créer y ai accès. Si je comprend ce que tu dit, le fait que mes thread font des sendmessage sur le handle de ma listbox, mm en même temps ne créer pas de problème car en fait les messages (aussi en général ?) sont éxécuté séquentiellement c'est bien cela ?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 15 nov. 2007 à 18:15
A savoir si la séquence sera celle que tu escomptes, je ne m'y fierais pas trop.
thrd1:
- SendMessage(hlst, LB_GETCOUNT, 0, 0);
thrd2 a placé un LB_RESETCONTENT dnas la pile d'appels entre 2...
thrd1 continue en voulant traiter les items...
deck_bsd
Messages postés1243Date d'inscriptionjeudi 31 mars 2005StatutMembreDernière intervention 3 août 20162 15 nov. 2007 à 18:52
ok pour l'exemple BruNews, donc vaut mieu faire la synchronisation, c'est vrai que j'avai vu dans richter un tableau comparatif entre les mutex et le zone critique. Je vai lire le texte ce rapportant à ceux-ci. Je verais bien ce que je ferais :D