NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un test atomique sur une variable. Cela _peut_ servir de mutex sur des zones de mémoire partagée (encore qu'on puisse utiliser un mutex dans la même variable partagée sous certaines conditions), mais cela sert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les threads et l'autre (les sémaphores) c'est pour les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside da ns la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la pui ssance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
remy
-- http://remyaumeunier.chez-alice.fr/
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès
concurrents. Un sémaphore, c'est une décrémentation et un test
atomique sur une variable. Cela _peut_ servir de mutex sur des zones
de mémoire partagée (encore qu'on puisse utiliser un mutex dans la
même variable partagée sous certaines conditions), mais cela sert
aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus
haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les
threads et l'autre (les sémaphores) c'est pour les processus leur
finalité est la même
partager une ressource ou faire une syncro la différence réside da ns la
sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate
http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un
lock et tu attends
de tout manier je peut te faire la même chose en c , java pour les
thread, ou basic avec une double liste et un boolean
et l'algo sera le même si si ,la différence résidera dans la pui ssance
des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux
essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera,
ça explorsera en vol et tu chercheras longtemps la source du
problème.
non il y a une doubles liste
entre -> fifo -> boolean ->fifo ->sortie
NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un test atomique sur une variable. Cela _peut_ servir de mutex sur des zones de mémoire partagée (encore qu'on puisse utiliser un mutex dans la même variable partagée sous certaines conditions), mais cela sert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les threads et l'autre (les sémaphores) c'est pour les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside da ns la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la pui ssance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
remy
-- http://remyaumeunier.chez-alice.fr/
remy
remy a écrit :
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un te st atomique sur une variable. Cela _peut_ servir de mutex sur des zon es de mémoire partagée (encore qu'on puisse utiliser un mutex dan s la même variable partagée sous certaines conditions), mais cela s ert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les threads et l'autre (les sémaphores) c'est po ur les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside d ans la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la puissance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui rest era, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
la double liste c'est pour un cas a la con je ne me souvient plus lequel
-- http://remyaumeunier.chez-alice.fr/
remy a écrit :
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès
concurrents. Un sémaphore, c'est une décrémentation et un te st
atomique sur une variable. Cela _peut_ servir de mutex sur des zon es
de mémoire partagée (encore qu'on puisse utiliser un mutex dan s la
même variable partagée sous certaines conditions), mais cela s ert
aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus
haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les threads et l'autre (les sémaphores) c'est po ur
les processus leur finalité est la même
partager une ressource ou faire une syncro la différence réside d ans
la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate
http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve
un lock et tu attends
de tout manier je peut te faire la même chose en c , java pour les
thread, ou basic avec une double liste et un boolean
et l'algo sera le même si si ,la différence résidera dans la
puissance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux
essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui rest era,
ça explorsera en vol et tu chercheras longtemps la source du
problème.
non il y a une doubles liste
entre -> fifo -> boolean ->fifo ->sortie
la double liste c'est pour un cas a la con je ne me souvient plus lequel
NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un te st atomique sur une variable. Cela _peut_ servir de mutex sur des zon es de mémoire partagée (encore qu'on puisse utiliser un mutex dan s la même variable partagée sous certaines conditions), mais cela s ert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
l'un est fait pour les threads et l'autre (les sémaphores) c'est po ur les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside d ans la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la puissance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui rest era, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
la double liste c'est pour un cas a la con je ne me souvient plus lequel
-- http://remyaumeunier.chez-alice.fr/
JKB
Le Mon, 10 Jan 2011 10:22:50 +0100, remy écrivait :
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un test atomique sur une variable. Cela _peut_ servir de mutex sur des zones de mémoire partagée (encore qu'on puisse utiliser un mutex dans la même variable partagée sous certaines conditions), mais cela sert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ? Non. Conclusion ?
l'un est fait pour les threads et l'autre (les sémaphores) c'est pour les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside dans la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu léve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la puissance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ? Tu montres seulement que tu ne sais pas ce que ça implique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 10 Jan 2011 10:22:50 +0100,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès
concurrents. Un sémaphore, c'est une décrémentation et un test
atomique sur une variable. Cela _peut_ servir de mutex sur des zones
de mémoire partagée (encore qu'on puisse utiliser un mutex dans la
même variable partagée sous certaines conditions), mais cela sert
aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus
haut un sémaphore avec un mutex voir fonction lecture
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ?
Non. Conclusion ?
l'un est fait pour les
threads et l'autre (les sémaphores) c'est pour les processus leur
finalité est la même
partager une ressource ou faire une syncro la différence réside dans la
sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate
http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu léve un
lock et tu attends
de tout manier je peut te faire la même chose en c , java pour les
thread, ou basic avec une double liste et un boolean
et l'algo sera le même si si ,la différence résidera dans la puissance
des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux
essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera,
ça explorsera en vol et tu chercheras longtemps la source du
problème.
non il y a une doubles liste
entre -> fifo -> boolean ->fifo ->sortie
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ?
Tu montres seulement que tu ne sais pas ce que ça implique.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 10 Jan 2011 10:22:50 +0100, remy écrivait :
JKB a écrit :
un mutex ou un sémaphore c'est la même chose,
NON ! Un mutex, c'est un point d'arrêt pour régler les accès concurrents. Un sémaphore, c'est une décrémentation et un test atomique sur une variable. Cela _peut_ servir de mutex sur des zones de mémoire partagée (encore qu'on puisse utiliser un mutex dans la même variable partagée sous certaines conditions), mais cela sert aussi à un tas d'autres choses.
je te signal que j'ai codée avec mais petits doigt voir un peut plus haut un sémaphore avec un mutex voir fonction lecture
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ? Non. Conclusion ?
l'un est fait pour les threads et l'autre (les sémaphores) c'est pour les processus leur finalité est la même partager une ressource ou faire une syncro la différence réside dans la sémantique et l'environnement dans lequel ils sont utilisés
Mon dieu... N'utilise que des mots que tu comprends.
Des exemples on en trouve autant qu'on veut sur activestate http://code.activestate.com/recipes/
c'est de la syncro a la portée du premier couillon qui passe tu léve un lock et tu attends de tout manier je peut te faire la même chose en c , java pour les thread, ou basic avec une double liste et un boolean et l'algo sera le même si si ,la différence résidera dans la puissance des obj ou des fonctions utilisées
Il te manque le mot _atomique_. Enfin, avec ton booléen, tupeux essayer. Ça fonctionnera dans 99% des cas et pour le 1% qui restera, ça explorsera en vol et tu chercheras longtemps la source du problème.
non il y a une doubles liste entre -> fifo -> boolean ->fifo ->sortie
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ? Tu montres seulement que tu ne sais pas ce que ça implique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
remy
JKB a écrit :
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ? Tu montres seulement que tu ne sais pas ce que ça implique.
tu rigole ,moi je ne sais rien
remy
-- http://remyaumeunier.chez-alice.fr/
JKB a écrit :
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ?
Tu montres seulement que tu ne sais pas ce que ça implique.
Et l'atomicité ? Est-ce que tu sais seulement ce que ça veut dire ? Tu montres seulement que tu ne sais pas ce que ça implique.
tu rigole ,moi je ne sais rien
remy
-- http://remyaumeunier.chez-alice.fr/
talon
remy wrote:
c'est de la syncro a la portée du premier couillon qui passe tu léve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un truc qui deadlocke de partout. Mais aller chercher la librairie Qt pour donner des exemples de threading en python il faut vraiment un couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gros
Pour étaler son inculture sur une aire importante, en effet, il il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilateur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de programmation conduisant à des deadlocks. Encore moins l'utilisation de librairie de haut niveau où on ne sait pas ce qui se passe. Et compter sur le compilateur, c'est rendre à peu près certain que ça ne marchera pas avec la version (n+1) du compilateur.
remy
--
Michel TALON
remy <remy@fctpas.fr> wrote:
c'est de la syncro a la portée du premier couillon qui passe tu léve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un
truc qui deadlocke de partout. Mais aller chercher la librairie Qt
pour donner des exemples de threading en python il faut vraiment un
couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gros
Pour étaler son inculture sur une aire importante, en effet, il
il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilateur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de
programmation conduisant à des deadlocks. Encore moins l'utilisation de
librairie de haut niveau où on ne sait pas ce qui se passe. Et compter
sur le compilateur, c'est rendre à peu près certain que ça ne marchera
pas avec la version (n+1) du compilateur.
c'est de la syncro a la portée du premier couillon qui passe tu léve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un truc qui deadlocke de partout. Mais aller chercher la librairie Qt pour donner des exemples de threading en python il faut vraiment un couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gros
Pour étaler son inculture sur une aire importante, en effet, il il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilateur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de programmation conduisant à des deadlocks. Encore moins l'utilisation de librairie de haut niveau où on ne sait pas ce qui se passe. Et compter sur le compilateur, c'est rendre à peu près certain que ça ne marchera pas avec la version (n+1) du compilateur.
remy
--
Michel TALON
remy
Michel Talon a écrit :
remy wrote:
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un truc qui deadlocke de partout.
cela ne deadlocke pas désoler
Mais aller chercher la librairie Qt
il existe des mutexs sans qt http://docs.python.org/library/mutex.html?highlight=mutex#module-mutex
fais le, tu verra,j'ai pris le premier truc qui me soit tombé sous la main, et actuellement je fais du qt donc
pour donner des exemples de threading en python il faut vraiment un couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gro s
Pour étaler son inculture sur une aire importante, en effet, il il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilate ur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de programmation conduisant à des deadlocks.
ou ils sont tes deadlocks
Encore moins l'utilisation de librairie de haut niveau où on ne sait pas ce qui se passe. Et compte r sur le compilateur, c'est rendre à peu près certain que ça ne mar chera pas avec la version (n+1) du compilateur.
remy
-- http://remyaumeunier.chez-alice.fr/
Michel Talon a écrit :
remy <remy@fctpas.fr> wrote:
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un
truc qui deadlocke de partout.
cela ne deadlocke pas désoler
Mais aller chercher la librairie Qt
il existe des mutexs sans qt
http://docs.python.org/library/mutex.html?highlight=mutex#module-mutex
fais le, tu verra,j'ai pris le premier truc qui me soit tombé sous la
main, et actuellement je fais du qt donc
pour donner des exemples de threading en python il faut vraiment un
couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gro s
Pour étaler son inculture sur une aire importante, en effet, il
il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilate ur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de
programmation conduisant à des deadlocks.
ou ils sont tes deadlocks
Encore moins l'utilisation de
librairie de haut niveau où on ne sait pas ce qui se passe. Et compte r
sur le compilateur, c'est rendre à peu près certain que ça ne mar chera
pas avec la version (n+1) du compilateur.
c'est de la syncro a la portée du premier couillon qui passe tu lé ve un
Ce qui est à la portée du premier couillon qui passe c'est de faire un truc qui deadlocke de partout.
cela ne deadlocke pas désoler
Mais aller chercher la librairie Qt
il existe des mutexs sans qt http://docs.python.org/library/mutex.html?highlight=mutex#module-mutex
fais le, tu verra,j'ai pris le premier truc qui me soit tombé sous la main, et actuellement je fais du qt donc
pour donner des exemples de threading en python il faut vraiment un couillon hors classe.
ces agencements doivent dater de début de l'aire informatique en gro s
Pour étaler son inculture sur une aire importante, en effet, il il ne faut pas être né du début de l'ère moderne.
plus de 40 à 50 ans
après la différence réside dans la transposition et le compilate ur
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de programmation conduisant à des deadlocks.
ou ils sont tes deadlocks
Encore moins l'utilisation de librairie de haut niveau où on ne sait pas ce qui se passe. Et compte r sur le compilateur, c'est rendre à peu près certain que ça ne mar chera pas avec la version (n+1) du compilateur.
Ni la transposition, ni le compilateur ne vont te sauver des erreurs de programmation conduisant à des deadlocks.
je te propose de charger la mule 3 tableaux (add,sup,lecture) de 10, 100, 1000, 10000 50000... threads chaqu'un
perso je n'ai pas fait le test, j'ai actuellement du taf sur le feux si python tient la charge mon code devrait tenir lui aussi sauf erreur ...
remy
-- http://remyaumeunier.chez-alice.fr/
talon
JKB wrote:
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ? Non. Conclusion ?
Si tu te contentes de synchroniser des threads d'un même processus, il est évident qu'on peut simuler un sémaphore avec une variable protégée par un mutex qu'on incrémente ou décrémente. Il faut aussi un mécanisme pour que plusieurs threads puissent attendre que la variable s'annule, ce qui se réalise avec une variable de condition. En python les choses sont différentes, car si pour un mutex natif, seul le thread qui l'a verrouillé peut le déverrouiller, en python n'importe quel thread peut déverrouiiler le mutex. C'est bien sûr car le mutex de python est implémenté par un mutex plus une variable de condition, et pourquoi il n'y a pas besoin de variable de condition en python. En fait le module "threading" de python réimplemente toutes sortes de constructions standard, sémaphores, variables de condition, etc. en pur python à partir de la construction ci-dessus.
Si maintenant il s'agit de synchroniser plusieurs processus, il n'y a pas de construction de sémaphore possible par des méthodes similaires, sauf à recourir à des appels systèmes spécifiques (sémaphores system V ou posix) ou des bidouilles via le système de fichiers (créer des fichiers verrouillés avec fcntl).
--
Michel TALON
JKB <jkb@koenigsberg.invalid> wrote:
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ?
Non. Conclusion ?
Si tu te contentes de synchroniser des threads d'un même processus, il
est évident qu'on peut simuler un sémaphore avec une variable protégée
par un mutex qu'on incrémente ou décrémente. Il faut aussi un mécanisme
pour que plusieurs threads puissent attendre que la variable s'annule,
ce qui se réalise avec une variable de condition. En python les choses
sont différentes, car si pour un mutex natif, seul le thread qui l'a
verrouillé peut le déverrouiller, en python n'importe quel
thread peut déverrouiiler le mutex. C'est bien sûr car le mutex de
python est implémenté par un mutex plus une variable de condition, et
pourquoi il n'y a pas besoin de variable de condition en python. En fait
le module "threading" de python réimplemente toutes sortes de
constructions standard, sémaphores, variables de condition, etc. en pur
python à partir de la construction ci-dessus.
Si maintenant il s'agit de synchroniser plusieurs processus, il n'y a
pas de construction de sémaphore possible par des méthodes similaires,
sauf à recourir à des appels systèmes spécifiques (sémaphores system V
ou posix) ou des bidouilles via le système de fichiers (créer des
fichiers verrouillés avec fcntl).
Et alors ? Est-ce que ça implique qu'un sémaphore est un mutex ? Non. Conclusion ?
Si tu te contentes de synchroniser des threads d'un même processus, il est évident qu'on peut simuler un sémaphore avec une variable protégée par un mutex qu'on incrémente ou décrémente. Il faut aussi un mécanisme pour que plusieurs threads puissent attendre que la variable s'annule, ce qui se réalise avec une variable de condition. En python les choses sont différentes, car si pour un mutex natif, seul le thread qui l'a verrouillé peut le déverrouiller, en python n'importe quel thread peut déverrouiiler le mutex. C'est bien sûr car le mutex de python est implémenté par un mutex plus une variable de condition, et pourquoi il n'y a pas besoin de variable de condition en python. En fait le module "threading" de python réimplemente toutes sortes de constructions standard, sémaphores, variables de condition, etc. en pur python à partir de la construction ci-dessus.
Si maintenant il s'agit de synchroniser plusieurs processus, il n'y a pas de construction de sémaphore possible par des méthodes similaires, sauf à recourir à des appels systèmes spécifiques (sémaphores system V ou posix) ou des bidouilles via le système de fichiers (créer des fichiers verrouillés avec fcntl).
