C++ Girl
  1. C++ Girl
  3. Comment utiliser la mémoire partagée et mutex nommée entre un service Windows et un processus?
Intereting Posts
Serveur / Client TCP asynchrone (winsock) // Problème FD_WRITE Le modèle de classe peut être instancié sans membres? Où dois-je placer la source de tests unitaires et exposer les composants internes? C / C ++ Créer une énumération avec des valeurs négatives, sans avoir à la numéroter Pourquoi certains programmeurs expérimentés écrivent-ils des comparaisons avec la valeur précédant la variable? Comment obtenir un .pyd pour Windows python à partir du code source c / c ++? (mise à jour: rapide maintenant en Python si c’est ce que vous voulez) Interpolation bilinéaire SSE Compilateur VC ++ / source-charset: utf-8 ne fonctionne pas Avantage de la macro par rapport à la ligne en C ++ La conversion de littéral de chaîne en char * est obsolète ‘hash_map’ n’a pas été déclaré dans cette étendue avec g ++ 4.2.1 problème avec la mise à jour d’une carte en supprimant des clés et des éléments obtenir l’heure locale avec boost erreur: iostream.h en raison de l’inclusion de cplex Lors de la surcharge de l’opérateur d’égalité ==, faut-il d’abord vérifier l’égalité de référence?

Comment utiliser la mémoire partagée et mutex nommée entre un service Windows et un processus?

J’ai un code écrit en C ++ \ MFC qui est exécuté en tant que service Windows et processus Windows (normal) C ++ \ MFC – je souhaite maintenant communiquer entre eux en utilisant Mutex et Shared memory (File mapping).

Comment est-ce possible ?

Cela dépend de vos besoins en communication. Généralement, le service crée le mutex et la mémoire partagée, que les clients ouvrent et font. OutputDebugSsortingng () est un exemple classique d’IPC utilisant un mutex et une mémoire partagée (et certains événements). Voici un examen détaillé du fonctionnement de OutputDebugSsortingng (); vous pouvez faire quelque chose de similaire.

Je suggère ce qui suit

  1. service crée un mutex, 2 événements et un fichier mappé en mémoire (mmf), tous nommés

  2. lorsque le service doit envoyer des données à l’autre processus

    une. prend possession du mutex

    b. écrit des données sur mmf

    c. signale l’événement n ° 1, ce qui signifie que le service dispose de nouvelles informations pour le programme

    ré. libère le mutex

  3. quand le programme veut envoyer des données au service

    une. prend possession du mutex

    b. écrit des données sur mmf

    c. signale l’événement n ° 2, ce qui signifie que le programme dispose de nouvelles informations pour le service

    ré. libère le mutex

  4. le service vérifie si l’événement n ° 2 est activé. Si ce n’est pas le cas, sinon:

    une. prend possession du mmf

    b. lit les données

    c. réinitialise l’événement n ° 2

    ré. libère mutex

  5. le programme vérifie si l’événement n ° 1 est activé. Si ce n’est pas le cas, sinon:

    une. prend possession du mmf

    b. lit les données

    c. réinitialise l’événement n ° 1

    ré. libère mutext

Le problème avec cette approche est que des messages peuvent être perdus (lorsque, par exemple, le service parvient à écrire 2 messages consécutifs, avant que le programme ne puisse lire le premier) ET qu’un seul processus puisse s’attacher au service à propos de ça)

Je suggère une solution basée sur le socket, si cela est possible, où de tels problèmes ne surviennent pas.

PS vous pouvez utiliser le mmf pour créer une sorte de queue afin d’éviter le premier problème