Ce qui est plus rapide: SetEvent, SendMessage, PostMessage

Question

Environnement: Win32, C / C ++

Les trois (3) peuvent être utilisés par un thread pour signaler à main () qu'il a terminé une opération, par exemple.

Mais lequel est le signal le plus rapide de tous?

hmm ...

Answer 1

Les trois options nécessitent un commutateur de contexte de thread pour signaler le thread de réception. Il est fort probable que les frais généraux liés au changement de contexte surchargent toute différence de coût de traitement entre les API.

Le choix dépend probablement mieux de la nature du fil de réception, par exemple. s'agit-il d'un thread d'interface utilisateur et / ou exécute-t-il une boucle de message? Cela dit, certains détails précis incluent:

• SendMessage est utile lorsque le thread de réception est un thread d'interface utilisateur qui tourne dans une boucle de message. Le thread d'envoi bloque jusqu'à ce que le destinataire traite le message. Mais il peut gérer les messages sans file d'attente pendant cette période. Cette logique pourrait potentiellement ralentir les choses, car des changements de contexte supplémentaires pourraient être impliqués, faisant de SendMessage le plus lent des trois.

• PostMessage est également utile. lorsque le destinataire est dans une boucle de message. La différence avec SendMessage est qu’il n’attend pas que le destinataire traite le message, ce qui entraîne moins de temps système.

• SetEvent est utile lorsque le thread récepteur peut attendre sur un objet événement, par exemple avec WaitForSingleObject (). Il ne subit aucune surcharge de traitement de message ni de marshaling, et risque de réagir plus rapidement que les autres.

Answer 2

SetEvent est de loin le plus rapide et le plus simple, mais il peut également contenir le moins d’informations. En gros, tout ce que l’on peut dire, c’est que quelque chose s’est passé (l’événement a été signalé), rien de plus.

Answer 3

Je n'ai pas vérifié, mais (en supposant que quelqu'un attend l'objet), je dirais SetEvent, SendMessage et enfin PostMessage.

Modifier: Le raisonnement qui précède est simplement que SendMessage est synchrone et que PostMessage est asynchrone. Je ne suis pas sûr de SetEvent, mais je suppose que cela déclenche l'attente de l'événement sans avoir à attendre que la pompe de messages transmette le message. Le fait d’envoyer ou de poster n’importe probablement pas, c’est juste une question de savoir si la partie expéditrice attendra ou non. Le traitement interne est probablement identique.

Toutefois, ni l'envoi ni l'envoi de message ne sont normalement ceux que vous utiliseriez pour envoyer un signal à un autre thread.

Answer 4

Si vous examinez MsgWaitForMultipleObjects vs WaitForMultipleObjects, vous verrez que le nombre maximal d’objets en attente pour MsgWaitForMultipleObjects est inférieur à WaitForMultipleObjects, ce qui signifie qu’il existe un événement masqué " on; donc un message aura la surcharge d'un événement + le message qui passe