semaphore.h, ou comment faire croire que ça existe... |
Bienvenue invité ( Connexion | Inscription )
Il est interdit de poster directement à la racine de ce forum.
Veuillez créer votre topic dans le sous-forum approprié.
semaphore.h, ou comment faire croire que ça existe... |
3 Aug 2004, 23:21
Message
#1
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
J'ai besoin de sémaphores.... avec des pthreads. Je m suis dis que le semaphore.h serait tout à fait judicieux.... mais voilà, c'est implémenté à moitié, faut passer par sem_open() et non sem_init() qui n'est pas implémenté (étonnant puisque la focntion est présente dans le .h enfin..).
Y a quoi d'autre, parce qu'à coup de sem_open je n'arrive pas à m'en sortir, j'ai des erreurs dans tous les coins sur les sem_wait etc. -------------------- Nothing Else Matters
|
|
|
3 Aug 2004, 23:38
Message
#2
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
sem_init est facultatif.
Ca marche pas un truc du style CODE sem_t *s; s=sem_open("foo",O_CREAT,0,0); sem_wait(s); Sinon si tu écris tu code nouveau et tu fais que du dev sur mac, la librarie MP est souvent plus simple d'utilisation. -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
4 Aug 2004, 00:08
Message
#3
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
pb sem_wait: Bad file descriptor
sem.h c'est assez inbuvable.... Je sais pas si je les utilise mal.... mon but c'est de faire passer un certains nombres de tâches dedans et ensuite de les libérer en même temps (je vais peut-être ajouter un mutex...) [edit]et il faut que je reste portable -------------------- Nothing Else Matters
|
|
|
4 Aug 2004, 00:32
Message
#4
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
C'est bizarre ces sémaphores de chez sem_open, ils continuent à exister après l'exécution du programme, alors si tu les crée avec aucun droit comme je l'ai fait, tu peu plus utiliser de sémaphores avec ce nom là, puisque tu n'as pas les droits pour reouvrir le sémaphore pour le fermer.
En fait ces sémaphore là m'ont tout l'air de plus être un truc d'ipc Y'a un message sur les sémaphores ici. De toute façon ça doit pas être la mort de refaire des sémaphore avec des mutex, même si c'est moins efficace qu'un "vrai" sémaphore. edit: tu peux même trouver ça ici, avec le .h ici Ce message a été modifié par f_cam - 4 Aug 2004, 00:35. -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
4 Aug 2004, 00:36
Message
#5
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
merci
je me suis aussi fait avoir en oublant de détruire mes sémaphores .... Il les fou où? Y a pas un moyen externe d'aller les killer? -------------------- Nothing Else Matters
|
|
|
4 Aug 2004, 00:47
Message
#6
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
bein en tournant en tant que root tu pourras toujours les ouvrir et les tuer.
Il me semble que c'est implémenté via shm_open et companie. -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
5 Aug 2004, 02:19
Message
#7
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
y a une notion de rendez-vous en C ?
-------------------- Nothing Else Matters
|
|
|
5 Aug 2004, 02:24
Message
#8
|
|
Macbidouilleur de vermeil ! Groupe : Membres Messages : 1 318 Inscrit : 7 May 2003 Lieu : Ile de France (92) Membre no 7 472 |
QUOTE(dulrich1 @ 5 Aug 2004, 03:19) y a une notion de rendez-vous en C ? [right][snapback]799923[/snapback][/right] Tu entends quoi par là ? -------------------- @+ Driden |
|
|
5 Aug 2004, 02:33
Message
#9
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
CODE int n = 2; /* Nombre de taches */ pthread_cond_t *cond; pthread_mutex_t *verrou; void rendez_vous () { pthread_mutex_lock (verrou); n = n - 1; if (n == 0) pthread_cond_broadcast (cond); else pthread_cond_wait (cond, mutex); n = n + 1; pthread_mutex_unlock (verrou); } un truc pas trop loin de ça ..... je pensais à un type de rendez-vous proche de celui qui existe en ada... où tu peux filer des données d'une tâche à une autre de manière assez simple, sans générer d'attente active. Cela permet de gérer particulièrement bien le synchronisme.... En gros j'aurais besoin d'une tache de contrôle qui contient un tableau de valeurs, plusieurs taches (un nombre variable au cours du temps) vient chercher une à une ces valeurs et les traite (elle traitent toutes la même valeur en même temps (elles doivent commencer le traitement en même temps). Quand le traitement de toutes les valeurs a été fait on ajoute une tache... et ainsi de suite. mais je vois que je vais devoir le réinventer :/ .... -------------------- Nothing Else Matters
|
|
|
5 Aug 2004, 02:41
Message
#10
|
|
Macbidouilleur de vermeil ! Groupe : Membres Messages : 1 318 Inscrit : 7 May 2003 Lieu : Ile de France (92) Membre no 7 472 |
QUOTE(dulrich1 @ 5 Aug 2004, 03:33) mais je vois que je vais devoir le réinventer :/ .... [right][snapback]799929[/snapback][/right] Je pense aussi, ça fait parti des joies du C. -------------------- @+ Driden |
|
|
5 Aug 2004, 04:49
Message
#11
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
Bon ben j'ai réussis à obtenir ce que je voulais finalement ...
Il ne me reste plus qu'à développer la partie "bench", parce que pour l'instant ça teste un peu n'importe quoi.... si quelqu'un est intéressé, c'est avec plaisir ... Le but étant de tester le débit (éventuellement les temps d'accès) de n'importe quel disque passé en argument.... On teste le débit pour une tache, puis deux, puis trois puis........ ça devrait bouchonner assez rapidement. Ensuite on peut facilement recracher les résultats et les parser pour en faire un graphe tri-dimensionnel.... enfin CODE #include <pthread.h>
#include <sys/time.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define NBR_TASK_MAX 15 #define NBR_ECHANTILLONS_MAX 50 //taille des paquets a ecrire int size_buffer[] = { 4, 8, 16, 32, 64, 128, 256, 512, 1024};// 2048, 16384}; //mutex de sync des taches de bench int n = 0; /* Nombre de taches */ pthread_cond_t cond; pthread_mutex_t verrou; void rendez_vous () { pthread_mutex_lock (&verrou); n = n - 1; if (n == 0) pthread_cond_broadcast (&cond); else pthread_cond_wait (&cond, &verrou); n = n + 1; pthread_mutex_unlock (&verrou); } //mutex global utilise par la tache de control pour lancer les taches //suivantes int m = 1; /* Nombre de taches init a 1 a cause de la tache de control*/ pthread_cond_t cond_glob; pthread_mutex_t verrou_glob; void rendez_vous_glob () { pthread_mutex_lock (&verrou_glob); m = m - 1; if (m == 0) pthread_cond_broadcast (&cond_glob); else pthread_cond_wait (&cond_glob, &verrou_glob); m = m + 1; pthread_mutex_unlock (&verrou_glob); } //tache de bench bouclant sur le tableau de la taille des buffer void *thr_bench(void * arg) { //on prepare les fichiers de sortie FILE *fout; struct timeval tp1; struct timeval tp2; double s1, s2, m1, m2; double total = 0, temp; //echantillonage cad nombre de test d'ecriture int nbr_echant = NBR_ECHANTILLONS_MAX, nbr_echant_i; unsigned int iter_buf; unsigned max_iter_buff = sizeof(size_buffer)/sizeof(int); for( iter_buf = 0; iter_buf < max_iter_buff; iter_buf++) { int size_kilo = size_buffer[iter_buf]; //la taille d'un char fait 1 octet char *buf = (char*)malloc (sizeof(char)*(size_kilo*1000)); rendez_vous(); for( nbr_echant_i = nbr_echant; nbr_echant_i > 0; nbr_echant_i--) { gettimeofday(&tp1,0); s1 = tp1.tv_sec; m1 = tp1.tv_usec; fout = tmpfile(); fwrite(buf,1, size_kilo*1000,fout); gettimeofday(&tp2,0); s2 = tp2.tv_sec; m2 = tp2.tv_usec; temp = s2-s1+(m2-m1)/1000000; total = total + temp; fclose(fout); } printf("%d Ko en %lf sec = %lf Mo/s\n" , size_kilo, total/nbr_echant, (size_kilo/(total/nbr_echant))/1000 ); free(buf); sleep(1); } rendez_vous_glob(); pthread_exit(NULL); } //tache de control, lance paquet de tache par paquet de taches void *thr_control(void * arg) { unsigned int nbr_task; unsigned int iter_thr; for(nbr_task = 1; nbr_task < NBR_TASK_MAX; nbr_task++) { pthread_t thr[nbr_task]; pthread_mutex_lock (&verrou); n++; pthread_mutex_unlock (&verrou); pthread_mutex_lock (&verrou_glob); m++; pthread_mutex_unlock (&verrou_glob); for (iter_thr = 0; iter_thr < nbr_task; iter_thr++) { pthread_create(&thr[iter_thr], NULL, thr_bench, NULL ); } rendez_vous_glob(); } pthread_exit(NULL); } //main, initialise les mutex et lance la tache de control int main (int argc, const char * argv[]) { pthread_t thr; //initialisation des mutex if (pthread_mutex_init (&verrou, NULL) == -1) printf ("Error setting up mutex"); if (pthread_cond_init (&cond, NULL) == -1) printf ("Error setting up condition signal"); if (pthread_mutex_init (&verrou_glob, NULL) == -1) printf ("Error setting up mutex"); if (pthread_cond_init (&cond_glob, NULL) == -1) printf ("Error setting up condition signal"); pthread_create(&thr, NULL, thr_control, NULL ); pthread_exit(NULL); }
Fichier(s) joint(s)
main.c.zip ( 1.37 Ko )
Nombre de téléchargements : 102
image.jpg ( 46.71 Ko ) Nombre de téléchargements : 169 -------------------- Nothing Else Matters
|
|
|
5 Aug 2004, 07:06
Message
#12
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 779 Inscrit : 7 Jan 2003 Lieu : Montréal Membre no 5 496 |
Petit commentaire vis à vis du message plus haut : il est pas facile du tout (je suppose qu'il doit y avoir moyen en ligne de commande et en root, mais ....) d'effacer un sémaphore natif OSX créé par Xcode, si le code pour le détruire n'est pas dans l'appli elle même.
La dernière fois que j'ai utilisé des sémaphores, j'ai en fait rajouté le code pour les détruire jsute avant la déclaration pour les créer, ce qui simplifiait le problème (en débug pas à pas, j'allais pas m'amuser à attendre qu'un programme buggé aille exécuter le free sur les sémaphores, ça risquait de durer une petite infinité de temps). Voilà, c'était le conseil débile du jour. Mais ça m'avait économisé pas mal de prise de tête (et quelques kernels panic au début, quand je savais pas que les semaphores OSX étaient pas tout à fait comme les autres. Je trouve ça débile d'ailleurs que ça compile alors qu'une fonction est pas implémentée, je suppose que c'est pour pouvoir programmer multiplateforme, mais il devrait y avoir un warning quand on compile pour OSX !). Ce message a été modifié par guiguiguillaume - 5 Aug 2004, 07:06. -------------------- guigui - 15,2" et même 20 de plus pour laisser courir le tigre.
|
|
|
5 Aug 2004, 09:20
Message
#13
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 2 833 Inscrit : 19 Jul 2001 Lieu : Живим у Греноблу Membre no 519 |
Pour info, mais je ne suis pas bien sur de moi là dessus car je n'ai utilisé que les NSLock, il me semble que les sémaphores ne sont pas implémentés correctement sous OS X. Je parle des sémaphores comme sous Linux.
En fait, il faudrait utiliser le système de mutex du noyau Mach. Pour que ton code soit portable, il faut peut-être que tu fasses un ensemble de fonctions qui diffère selon l'OS grâce à des directives de précompilation. CODE #ifdef _MAC_OS_X_ my_sem_open() { ... } ... #endif #ifdef _LINUX_ my_sem_open() { ... // instructions différentes } ... #endif En ce qui conerne les sémaphores qui fonctionnent mal ou pas sur OS X, c'est à confirmer car je ne suis pas sur de moi. -------------------- Хајде Јано коло да играмо
iMac 27 mi 2010 Macbook air mi 2011 Mac Mini M2 |
|
|
5 Aug 2004, 11:29
Message
#14
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
QUOTE(guiguiguillaume @ 5 Aug 2004, 08:06) Petit commentaire vis à vis du message plus haut : il est pas facile du tout (je suppose qu'il doit y avoir moyen en ligne de commande et en root, mais ....) d'effacer un sémaphore natif OSX créé par Xcode, si le code pour le détruire n'est pas dans l'appli elle même. La dernière fois que j'ai utilisé des sémaphores, j'ai en fait rajouté le code pour les détruire jsute avant la déclaration pour les créer, ce qui simplifiait le problème (en débug pas à pas, j'allais pas m'amuser à attendre qu'un programme buggé aille exécuter le free sur les sémaphores, ça risquait de durer une petite infinité de temps). Voilà, c'était le conseil débile du jour. Mais ça m'avait économisé pas mal de prise de tête (et quelques kernels panic au début, quand je savais pas que les semaphores OSX étaient pas tout à fait comme les autres. Je trouve ça débile d'ailleurs que ça compile alors qu'une fonction est pas implémentée, je suppose que c'est pour pouvoir programmer multiplateforme, mais il devrait y avoir un warning quand on compile pour OSX !). [right][snapback]799981[/snapback][/right] La fonction est, d'une certaine façon impémentée. Il y a le symbole qu'il faut dans la libSystem (j'ai vérifié avec nm). Donc pour le compilo/linker difficile de savoir que le code source de la fonction sem_init se résume à int sem_init(sem_t *, int, unsigned int){ return SEM_FAILED; } -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
8 Aug 2004, 22:44
Message
#15
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
effectivement, avec plein de threads ça va pas être la joie, d'autant que dans panther tu as un gros mutex bien baveux dans le kernel qui garde l'entrée à tout ce qui est fichiers (et un autre pareil pour le stack tcp/ip)
-------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
8 Aug 2004, 23:10
Message
#16
|
|
Méchant modérateur paranoïaque Groupe : Modérateurs Messages : 10 755 Inscrit : 24 Jan 2002 Lieu : Confoederatio Helvetica, Kanton Wallis Membre no 1 865 |
QUOTE(f_cam @ 8 Aug 2004, 23:44) effectivement, avec plein de threads ça va pas être la joie, d'autant que dans panther tu as un gros mutex bien baveux dans le kernel qui garde l'entrée à tout ce qui est fichiers (et un autre pareil pour le stack tcp/ip) [right][snapback]803542[/snapback][/right] pas être la joie pour? pour écrire sur le disque chaque tâche a son propre fichier... pour le reste j'ai pu m'arranger avec les rendez-vous (pseudo) collés plus haut. -------------------- Nothing Else Matters
|
|
|
8 Aug 2004, 23:24
Message
#17
|
|
Moderating Daemon Groupe : Modérateurs Messages : 6 345 Inscrit : 22 Feb 2004 Lieu : Yvelines/Cambridge (GB), dans mon pantalon Membre no 15 207 |
pour avoir des gros débits.
Ce mutex est global, il s'applique à tous les fichiers, de tous les threads de tous les applis. -------------------- G5 Bi 2GHz rev A, ATI X800 XT
Alu 17" rev A MacBook core duo 1.83 GHz |
|
|
19 Dec 2007, 15:47
Message
#18
|
|
Nouveau Membre Groupe : Membres Messages : 36 Inscrit : 25 Sep 2007 Membre no 95 586 |
CITATION(dulrich @ 5 Aug 2004, 02:33) [snapback]799929[/snapback] je pensais à un type de rendez-vous proche de celui qui existe en ada... où tu peux filer des données d'une tâche à une autre de manière assez simple, sans générer d'attente active. Cela permet de gérer particulièrement bien le synchronisme.... Non, tu n'as pas cela en C. C'est d'ailleurs la force d'Ada : avoir une lib de tasking et de gestion de la concurrence super forte au niveau sémantique, alors qu'en C, il faut que tu te dépatouilles toi-même à coup de mutex et autres conditions. Revers de la médaille : Ada nécessite une runtime pour gérer tout cela ... |
|
|
Nous sommes le : 24th September 2024 - 14:39 |