communication entre processus

[killwin]

Bonjour,

Voilà j'ai d'un côté un processus, un jeu de plateformes ( http://tuxworld.tuxfamily.org). Processus A

Et de l'autre côté un processus qui détermine la position des mains du joueur à l'aide de la kinect Xbox. Processus B

Question 1 :

Maintenant j'aimerais que le processus A questionne le processus B sur les coordonnées des mains du joueur. Mais il faut que ce soit rapide et efficace, pas de temps mort. Donc j'hésitais entre un échange de messages asynchronisés entre les processus , et faire une zone de mémoire partagée avec mutex. C'est quoi le mieux ? Si vous avez d'autres idées suis preneur.

Question 2 :

On peut forcer le système d'exploitation à partager les processus suivant les coeurs du processeur ?
Genre Core 1 -> processus A
Core 2 -> processus B

PS suis sous linux.

Merci

[white_tentacle]

Dans un premier lieu, j’utiliserai dbus. C’est assez facile à mettre en œuvre avec les bindings qt ou la glib, et tu peux faire des appels asynchrones.

Pour ta deuxième question, c’est presque un non-sens : laisse l’os gérer ça, les cas où tu sauras le faire mieux que lui sont extrêmement rares.

[killwin]

Merci,

Bon je me suis lancé dans dbus / glib. J'ai un peu galéré niveau librairies et fichiers entêtes dans mon cmake mais c'est résolu.

Par contre j'ai du mal à trouver des exemples et des tutoriaux. Je me suis basé là dessus, mais j'ai un horrible segfault.

http://www.ibm.com/developerworks/li...bus/index.html

Des sites sympas pour apprendre à envoyer des messages avec dbus ?

[white_tentacle]

Je te conseille, sauf si tu as une très bonne raison de ne pas le faire, d’utiliser les bindings qt. À défaut, rabats-toi sur la glib, mais ne fais pas du dbus natif --> ça ne servira qu’à te compliquer la vie.

Pour quelques exemples : http://doc.qt.digia.com/stable/intro-to-dbus.html

http://dbus.freedesktop.org/doc/dbus-tutorial.html

[killwin]

Merci,

J'ai un peu bossé sur dbus, avec qt c'est mort car la librairie est trop lourde juste pour dbus, j'ai préféré glib. Merci je dormirais moins bête ce soir.

Cependant pour résoudre mon problème je vais faire plus simple, lancer un thread avec mutex, plutôt que de complier deux programmes totalement séparés.

[killwin]

Maintenant je me retrouve avec un problème, j'ai l'impression que mon mutex ne marche pas :-(

J'ai les deux threads qui verrouillent en même temps :
J'ai à l'écran K L, puis M L

Merci

Main.cpp

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
pthread_mutex_t mutex; // variable globale
 
      if(th.lock()) {
printf("M L\n");
 
 
         for(unsigned k = 0; k < 640*480*3; k += 3) {
            matrix_partitions[k] = 0;
            matrix_partitions[k+1] = 0;
            matrix_partitions[k+2] = 0;
 
            if(partitions.at(k / 3)) {
               if(partitions.at(k / 3) == id_max)
               matrix_partitions[k] = 255;
            }
        }
printf("M U\n");
         th.unlock();
      }

kinect.cpp :

Code :

1
2
3
4
5
6
7
8
if(th.lock()) {
 
printf("K L\n");
id_max = Om_h.bigger();
partitions = Om_h.partitions();
printf("K U\n");
th.unlock();
}

thread.cpp :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
 
CThread::CThread(void *(*function)(void *))
{
 
   mutex = PTHREAD_MUTEX_INITIALIZER;
   thread.push_back(0);
 
   try {
           if(pthread_create(&thread.back(), NULL, (void *(*)(void *))function, NULL) < 0)
//       thread = SDL_CreateThread((int (*)(void *))function, NULL);
//       if(thread == NULL)
              throw string("thread.cpp : Can't create the thread");
   }
   catch(string caught) {
      cerr << caught << endl;
      throw;
   }
 
}
 
bool CThread::lock() {
   if(pthread_mutex_trylock(&mutex) != EBUSY)
      return true;
 
   return false;
}
 
void CThread::unlock() {
   pthread_mutex_unlock(&mutex);
}

[killwin]

Ha j'ai trouvé, en dehors des mutex mon thread accédait au même vecteur que le thread parent.

En fait j'avais omis le fait que
vector<float>a, b;

puis faire un a = b. Ca ne clone pas les vecteurs, donc je suis passé par a.assign(...) et ça marche beaucoup mieux.