Bonjour,
Comme beaucoup de personnes tu confonds Mac OS et Mac OS X qui sont deux
systèmes d'exploitation différents.
Ton problème actuel est, si je ne
m'abuse, uniquement sur du traitement de tableau de pointeurs, et pas
sur un de ces systèmes.
Comme le code que tu as posté est un petit fragment, avec des macros non
utilisés, des conditions d'entrée non défini, et aucun commentaire, ce
n'est pas simple de t'aider.
Fait un tout petit programme avec un main, qui compile, et poste le code
ici. Peut-être même qu'en faisant cela tu trouveras le problème.
Petites remarques : au lieu d'un gros define tout pourri, tu devrais
faire une fonction inline. Au lieu d'utiliser des constantes comme 64,
du devrait utiliser un define, ou mieux faire un sizeof idoine. Au lieu
de supposer que getpid retourne un int du devrait caster son résultat
pour le snprintf.
Enfin bref, le :
sem_t *sem;
(*sem) = (*(semaphores_nommes[semaphore]));
sem_open2(sem_ptr, ...);
Ne devrait-il pas être un truc du genre :
sem_t **sem;
*sem = semaphores_nommes[semaphore];
Car ton tableau de sémaphores est un tableau de 4 pointeurs, et tu
essaies d'accéder à la valeur pointée, et pointeur valant 3 (vu par le
printf), cela part en erreur (pas de mémoire en 0x3), bien sûr.
Remarque finale : le C c'est pas du LISP... :-)
Bonjour,
Comme beaucoup de personnes tu confonds Mac OS et Mac OS X qui sont deux
systèmes d'exploitation différents.
Ton problème actuel est, si je ne
m'abuse, uniquement sur du traitement de tableau de pointeurs, et pas
sur un de ces systèmes.
Comme le code que tu as posté est un petit fragment, avec des macros non
utilisés, des conditions d'entrée non défini, et aucun commentaire, ce
n'est pas simple de t'aider.
Fait un tout petit programme avec un main, qui compile, et poste le code
ici. Peut-être même qu'en faisant cela tu trouveras le problème.
Petites remarques : au lieu d'un gros define tout pourri, tu devrais
faire une fonction inline. Au lieu d'utiliser des constantes comme 64,
du devrait utiliser un define, ou mieux faire un sizeof idoine. Au lieu
de supposer que getpid retourne un int du devrait caster son résultat
pour le snprintf.
Enfin bref, le :
sem_t *sem;
(*sem) = (*(semaphores_nommes[semaphore]));
sem_open2(sem_ptr, ...);
Ne devrait-il pas être un truc du genre :
sem_t **sem;
*sem = semaphores_nommes[semaphore];
Car ton tableau de sémaphores est un tableau de 4 pointeurs, et tu
essaies d'accéder à la valeur pointée, et pointeur valant 3 (vu par le
printf), cela part en erreur (pas de mémoire en 0x3), bien sûr.
Remarque finale : le C c'est pas du LISP... :-)
Bonjour,
Comme beaucoup de personnes tu confonds Mac OS et Mac OS X qui sont deux
systèmes d'exploitation différents.
Ton problème actuel est, si je ne
m'abuse, uniquement sur du traitement de tableau de pointeurs, et pas
sur un de ces systèmes.
Comme le code que tu as posté est un petit fragment, avec des macros non
utilisés, des conditions d'entrée non défini, et aucun commentaire, ce
n'est pas simple de t'aider.
Fait un tout petit programme avec un main, qui compile, et poste le code
ici. Peut-être même qu'en faisant cela tu trouveras le problème.
Petites remarques : au lieu d'un gros define tout pourri, tu devrais
faire une fonction inline. Au lieu d'utiliser des constantes comme 64,
du devrait utiliser un define, ou mieux faire un sizeof idoine. Au lieu
de supposer que getpid retourne un int du devrait caster son résultat
pour le snprintf.
Enfin bref, le :
sem_t *sem;
(*sem) = (*(semaphores_nommes[semaphore]));
sem_open2(sem_ptr, ...);
Ne devrait-il pas être un truc du genre :
sem_t **sem;
*sem = semaphores_nommes[semaphore];
Car ton tableau de sémaphores est un tableau de 4 pointeurs, et tu
essaies d'accéder à la valeur pointée, et pointeur valant 3 (vu par le
printf), cela part en erreur (pas de mémoire en 0x3), bien sûr.
Remarque finale : le C c'est pas du LISP... :-)
#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
On 2010-04-16, JKB wrote:#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
Comme on peut le lire ici :
http://lists.apple.com/archives/unix-porting/2003/Feb/msg00133.html
MacOS X renvoie un file descriptor lors d'un appel a sem_open(), meme si
celui-ci est deguise en pointeur.
Je ne saurais te dire si cela casse une quelconque prescription dans
Posix. En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
On 2010-04-16, JKB wrote:
#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
Comme on peut le lire ici :
http://lists.apple.com/archives/unix-porting/2003/Feb/msg00133.html
MacOS X renvoie un file descriptor lors d'un appel a sem_open(), meme si
celui-ci est deguise en pointeur.
Je ne saurais te dire si cela casse une quelconque prescription dans
Posix. En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
On 2010-04-16, JKB wrote:#include <stdio.h>
#include <stdlib.h>
#include <semaphore.h>
int
main()
{
sem_t *s;
s = sem_open("/test", O_CREAT, S_IRUSR | S_IWUSR, 1);
printf("%pn", s);
sem_close(s);
sem_unlink("/test");
return(0);
}
Comme on peut le lire ici :
http://lists.apple.com/archives/unix-porting/2003/Feb/msg00133.html
MacOS X renvoie un file descriptor lors d'un appel a sem_open(), meme si
celui-ci est deguise en pointeur.
Je ne saurais te dire si cela casse une quelconque prescription dans
Posix. En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
Je vais continuer à réfléchir là dessus...
Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,
Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
Je vais continuer à réfléchir là dessus...
Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
Je vais continuer à réfléchir là dessus...
Le 16/04/10 18:28, JKB a écrit :Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
C'est exactement cela. Et la conséquence est que ceux qui vont
trifouiller dans ces structures opaques ont un jour ou l'autre un
problème de portabilité.
Donc : Pas joujou avec "sem_t *". On le stocke et on l'utilise quand on
en a besoin, on essaye pas de regarder ce qu'il y a dedans vu qu'il n'y
a pas toujours un dedans...Je vais continuer à réfléchir là dessus...
Voilà :-)
Le 16/04/10 18:28, JKB a écrit :
Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,
Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
C'est exactement cela. Et la conséquence est que ceux qui vont
trifouiller dans ces structures opaques ont un jour ou l'autre un
problème de portabilité.
Donc : Pas joujou avec "sem_t *". On le stocke et on l'utilise quand on
en a besoin, on essaye pas de regarder ce qu'il y a dedans vu qu'il n'y
a pas toujours un dedans...
Je vais continuer à réfléchir là dessus...
Voilà :-)
Le 16/04/10 18:28, JKB a écrit :Le 16-04-2010, ? propos de
Re: C, Mac OS X et sem_open,Je ne saurais te dire si cela casse une quelconque prescription dans
Posix.
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
En tout cas, je ne vois pas de raisons particulieres pour que ce
ne soit pas permis, et l'on devrait considerer qu'un sem_t * est un truc
completement opaque, dont la copie, par exemple, ne peut servir a rien.
Un peu comme un FILE *, quoi.
C'est exactement cela. Et la conséquence est que ceux qui vont
trifouiller dans ces structures opaques ont un jour ou l'autre un
problème de portabilité.
Donc : Pas joujou avec "sem_t *". On le stocke et on l'utilise quand on
en a besoin, on essaye pas de regarder ce qu'il y a dedans vu qu'il n'y
a pas toujours un dedans...Je vais continuer à réfléchir là dessus...
Voilà :-)
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Le 16/04/10 22:33, JKB a écrit :Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Relis les spés des sémaphores dans Posix. Il n'est pas dit que l'on
puisse utiliser le pointeur pour regarder là où il pointe. C'est une
valeur opaque. D'ailleurs pour regarder où ça pointerait il faudrait
connaître au moins un élément de la supposée structure. Et que dit la
norme Posix ? Rien bien sûr puisque que c'est un élément opaque. Rien à
voir, allez circulez !
De plus ton code n'a pas besoin de cela pour affecter la valeur du
pointeur à une variable, qu'il vaille 0x3 ou 0xbec04254. C'est en te
trompant, en partie à cause de toutes ces parenthèses, sur les
indirections que tu as essayé d'aller à l'adresse pointée.
J'espère que tu ne fais pas la même chose avec FILE... Il y a bien
longtemps on bidouillait directement dans la structure FILE, maintenant
personne ne fait cela. On a une valeur de pointeur, et on l'utilise dans
des appels de fonctions, que la valeur vaille 0x3 ou 0xbec04254.
Le 16/04/10 22:33, JKB a écrit :
Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Relis les spés des sémaphores dans Posix. Il n'est pas dit que l'on
puisse utiliser le pointeur pour regarder là où il pointe. C'est une
valeur opaque. D'ailleurs pour regarder où ça pointerait il faudrait
connaître au moins un élément de la supposée structure. Et que dit la
norme Posix ? Rien bien sûr puisque que c'est un élément opaque. Rien à
voir, allez circulez !
De plus ton code n'a pas besoin de cela pour affecter la valeur du
pointeur à une variable, qu'il vaille 0x3 ou 0xbec04254. C'est en te
trompant, en partie à cause de toutes ces parenthèses, sur les
indirections que tu as essayé d'aller à l'adresse pointée.
J'espère que tu ne fais pas la même chose avec FILE... Il y a bien
longtemps on bidouillait directement dans la structure FILE, maintenant
personne ne fait cela. On a une valeur de pointeur, et on l'utilise dans
des appels de fonctions, que la valeur vaille 0x3 ou 0xbec04254.
Le 16/04/10 22:33, JKB a écrit :Mac OS X 10.5 et 10.6 sont Posix car UNIX.
Non. Ils ne sont Posix qu'en partie (et je connais des Unix pas
Posix pour un sou). D'ailleurs, s'ils étaient parfaitement Posix,
mon problème n'existerait pas.
Relis les spés des sémaphores dans Posix. Il n'est pas dit que l'on
puisse utiliser le pointeur pour regarder là où il pointe. C'est une
valeur opaque. D'ailleurs pour regarder où ça pointerait il faudrait
connaître au moins un élément de la supposée structure. Et que dit la
norme Posix ? Rien bien sûr puisque que c'est un élément opaque. Rien à
voir, allez circulez !
De plus ton code n'a pas besoin de cela pour affecter la valeur du
pointeur à une variable, qu'il vaille 0x3 ou 0xbec04254. C'est en te
trompant, en partie à cause de toutes ces parenthèses, sur les
indirections que tu as essayé d'aller à l'adresse pointée.
J'espère que tu ne fais pas la même chose avec FILE... Il y a bien
longtemps on bidouillait directement dans la structure FILE, maintenant
personne ne fait cela. On a une valeur de pointeur, et on l'utilise dans
des appels de fonctions, que la valeur vaille 0x3 ou 0xbec04254.
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Le 17/04/10 09:46, JKB a écrit :
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Oui effectivement, mais comme Mac OS X ne supporte pas sem_open,
sem_destroy, sem_getvalue (voir
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/posix_sem.c>)
il n'y a pas de problème. :-) Pour avoir les sémaphores anonymes, Mac OS
X devra modifier son interface. Le projet Darwin étant public, tout le
monde peut changer cela. Mais comme cela fait bien des années que cela
n'a pas évolué (à part une couche de sécurité déployée), il semble que
ce n'est pas prêt de changer.Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Je ne sais pas si c'est la seule raison, mais c'est une raison
suffisante pour le moment. Le véritable problème je pense vient de Mach
qui n'a pas ces sémaphores et comme les sémaphores Posix sont mappés sur
les sémaphores Mach
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/osfmk/kern/sync_sema.c>...
Le 17/04/10 09:46, JKB a écrit :
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Oui effectivement, mais comme Mac OS X ne supporte pas sem_open,
sem_destroy, sem_getvalue (voir
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/posix_sem.c>)
il n'y a pas de problème. :-) Pour avoir les sémaphores anonymes, Mac OS
X devra modifier son interface. Le projet Darwin étant public, tout le
monde peut changer cela. Mais comme cela fait bien des années que cela
n'a pas évolué (à part une couche de sécurité déployée), il semble que
ce n'est pas prêt de changer.
Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Je ne sais pas si c'est la seule raison, mais c'est une raison
suffisante pour le moment. Le véritable problème je pense vient de Mach
qui n'a pas ces sémaphores et comme les sémaphores Posix sont mappés sur
les sémaphores Mach
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/osfmk/kern/sync_sema.c>...
Le 17/04/10 09:46, JKB a écrit :
Oui, sauf que tu oublies une contrainte. Convertir le plus
facilement un truc utilisant sem_init() en machin utilisant
sem_open(). Et là, ça coince parce que sem_init() peut s'utiliser
avec un sem_t tout ce qu'il y a de plus statique :
sem_t semaphore;
sem_init(&semaphore, 1);
alors que dans le cas sem_open(), c'est parfaitement impossible.
Oui effectivement, mais comme Mac OS X ne supporte pas sem_open,
sem_destroy, sem_getvalue (voir
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/posix_sem.c>)
il n'y a pas de problème. :-) Pour avoir les sémaphores anonymes, Mac OS
X devra modifier son interface. Le projet Darwin étant public, tout le
monde peut changer cela. Mais comme cela fait bien des années que cela
n'a pas évolué (à part une couche de sécurité déployée), il semble que
ce n'est pas prêt de changer.Là, je ne suis plus d'accord. Mon code est valable à partir du
moment où le sem_t * pointe sur quelque chose. Dans tous les Unix
testés (sauf Mac OS X), c'est vrai. Dans le cas Mac OS X, c'est faux
parce que le sem_t * est un entier qui n'a aucune raison de pointer
sur quelque chose de valable. Je commence même à comprendre pourquoi
il n'y a pas de sémaphores anonymes sous Mac OS X parce que le fait
d'utiliser un int pour une sem_t *, ça casse l'interface de
sem_init().
Je ne sais pas si c'est la seule raison, mais c'est une raison
suffisante pour le moment. Le véritable problème je pense vient de Mach
qui n'a pas ces sémaphores et comme les sémaphores Posix sont mappés sur
les sémaphores Mach
<http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/osfmk/kern/sync_sema.c>...