multithreading sous mac os leopard

Bonjours à tousse

Depuis quelque jour, j'essaye d'optimiser mon jeux video et je m'interaisse de très très près au multithreading. Seulement, j'ai tout les problèmes du monde avec les semaphores. En effet, parce que je suis sous mac, <semaphore.h> ne fonctionne pas. C'est alors que je me lance à 100% pour trouver une solution.

Au bous de quelques recherches google, je réussi à voir que <pthread.h> gère les sémaphores en voyant ce pdf : http://www.lita.univ-metz.fr/~paris/...s/SemMutex.pdf
Alors, heureux, je change vite mon code avec les fonctions listé en première page qui gère les sémaphores :mrgreen:. Mais lors de la compilation ... Fausse joie : les fonctions ne sont pas déclaré dans cette librarie contrairement ce qu'enseigne le pdf trouver sur internet. :calim2:


Ma question est : Comment puis je avoir un système de sémaphore stable pour mac OS X ?

Je vous remercie de votre lecture, ainsi que de votre aide éventuel étant la bienvenue.

Suite à de nombreuse heures de recherche, je suis enfin tombé sur une documentation relativement satisfaisante.

En effet, les sémaphores sous mac OS sont utilisés avec

Code:

---

1 2 3 4

#include <pthread.h> #include <mach/semaphore.h> #include <mach/task.h>

---

De cela, j'en ai créer quelque macros pour les comptabilités linux

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include <pthread.h>   #ifdef __APPLE__ #include <mach/semaphore.h> #include <mach/task.h>   #define semaphoreCreate(Semaphore, Number) semaphore_create (mach_task_self (), &(Semaphore), SYNC_POLICY_FIFO, (Number)) #define semaphoreWait(Semaphore) semaphore_wait ((Semaphore)) #define semaphoreSet(Semaphore) semaphore_signal ((Semaphore)) #define semaphoreDestroy(Semaphore) semaphore_destroy (mach_task_self (), (Semaphore))   #define semaphore_struct semaphore_t #else #include <semaphore.h>   #define semaphoreCreate(Semaphore, Number) sem_init (&(Semaphore), 0, (Number)) #define semaphoreWait(Semaphore) sem_wait (&(Semaphore)) #define semaphoreSet(Semaphore) sem_post (&(Semaphore)) #define semaphoreDestroy(Semaphore) sem_destroy (&(Semaphore))   #define semaphore_struct sem_t #endif

---

vous souhaitez instancier une semaphore ?

Code:

---

1 2	semaphore_struct MySemaphore ;

---

vous souhaitez initialiser une semaphore ?

Code:

---

1 2 3

semaphoreCreate (MySemaphore, TiketsLength) ; // TiketsLength étant le nombre de set/post que vous souhaité initialisé

---

vous souhaitez poster dans une semaphore ?

Code:

---

1 2	semaphoreSet (MySemaphore) ;

---

ou bien attendre une semaphore ?

Code:

---

1 2	semaphoreWait (MySemaphore) ;

---

et enfin : detruire une sémaphore ...

Code:

---

1 2	semaphoreDestroy (MySemaphore) ;

---

Peut être serai il bon de mettre ce post dans la faqs ... Ce qui serai, je pense, très utiles à bien d'autre personnes que moi. :mrgreen:

Ou bien utiliser boost::condition_variable ?

Puis je demande la raison d'utilisation d'un semaphore ?
C'est super rare d'en avoir besoin !

bonjours nicroman

Et bien, je n'utilise pas boost :oops:, mais néamoin, je peut te cité quelque exemple personnel de l'utilisation des sémaphores ... pour ma part, je développe un jeux vidéo.

J'utilise les sémaphores, pour effectuer du multithreading sur une fonction de height map.

(Height map, est un procédé de modélisation de terrain 3D en fonction du gris d'une image ex : le blanc d'une image sera une montagne, le noire sera une plaine voir, le font d'un océan)

Ma height map qui est chargé, est divisée en régions (comme des cartes routières), mon thread fils va faire des calculs de normales, de coordonné de textures et autres pour chaque régions, et à chaque foit qu'une région à été terminé par le thread fils, le thread père peut compilé une display liste OpengGL pendant que le fils s'attaque à la région suivante. Autant de thread fils exécutant la même fonction que de coeurs, mais sur une région différente de la carte en cours de chargement.

un autre exemple avec un systeme de buffer circulaire, est sur le chargement de texture pour opengl... en faite, pendant qu'un thread "attend" les accès disques pour charger un image dans la RAM, un autre transfert l'image précédemment charger de la RAM à la VRAM par OpenGL.

Les temps de chargement sont divisé presque par 2 !!!! (celons ma config, à savoir un ordinateur portable 2.5 Ghz, Bus à 1 Ghz, DD 5400trs/min, Nvidia 9600M GT)