Ici pas de question, mais une solution à un problème que j'ai eu du mal à résoudre ...
Mon modem a fonctionné pendant 2 ans sans problème avec une vieille version du driver userhand http://speedtouch.sourceforge.net.(...)
Une faille à jour de sécurité m'a contraint de le mettre à jour (>1.3)
Depuis j'étais confronté au problème de ne plus pouvoir me connecter, modem_run refusant (sans me dire pourquoi), de recharger le firmware.
En fouillant un peu dans la mailing list, un mutex (ou plutot un sémaphore) est créé et si celui-ci existe, modem_run quitte sans éffectuer le chargement.
la solution est d'exécuter cela afin de supprimer ce :
+# cleaning the mutex
+ipcs -a | grep 0xdeadbeef >/dev/null 2>&1
+if [ $? = 0 ]; then
+ ipcrm -S 0xdeadbeef
+fi
+
- pas de message explicatif sur l'echec du modem_run
- pas de possibilité de demander à modem_run de forcer le chargement du firmeware
Dans la mailing liste, on parle de mutex et pas de sémaphore, alors que l'on utilise IPC.
J'ai toujours cru qu'un mutex est un flag "non système" à l'interieur d'un processus, accessible uniquement par les threads de ce processus alors qu'un sémaphore est une "valeur système" accessible par plusieurs processus...
Les développeurs ont-ils commis une erreur de langage? Est ce moi qui ait des connaissances érronées?
Mathieu
Forum général.général speedtouch et modem_run
3
nov.
2004
# Un peu plus d'infos
Posté par Spike-Sp (site web personnel) . Évalué à 1.
[^] # Re: Un peu plus d'infos
Posté par mathieu mathieu (site web personnel) . Évalué à 1.
J'utilise un noyau 2.4.27
J'ai essayé il ya fort longtemps le driver du noyau et ca plantait ...
Je prefere utiliser le driver userhand car il est indépendant du noyau et je trouve ca plus simple (pas besoin de recompiler etc.).
# Version 1.3
Posté par Boa Treize (site web personnel) . Évalué à 2.
Un jour peut-être, je ferai une nouvelle tentative.
# Pourquoi mutex.
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
Un mutex est un service qui fait que tout demandeur du mutex reste bloqué si celui ci est déjà en cours d'utilisation.
Un sémaphore est une réserve de jetons, une fois la réserve epuisée, le demandeur de jeton est bloqué. Si un sémaphore ne possède qu'un jeton, son fonctionnement simule celui d'un mutex.
Donc moralité, ne pas confondre le contenu (marquer une ressource comme mutuellement exclusive) avec la forme (pthread mutex, sémaphore IPC à un jeton, futex, spinlock etc...)
[^] # Re: Pourquoi mutex.
Posté par mathieu mathieu (site web personnel) . Évalué à 1.
Désolé d'être pointilleux, je ne veux pas passer pour un emmerdeur. Je suis le premier à être reconnaissant du développement de ce driver que j'utilise depuis le début ;)
Fonctionnellement, un mutex fonctionne comme un semaphore à un seul jeton, là dessus pas de problème!
Mais pour moi la différence n'était pas que là, elle était surtout dans le fait que l'un fonctionne entre processus et pas l'autre ....
Ma vision s'approche plus de cette définition... http://www.webopedia.com/TERM/M/mutex.html(...)
Grande surprise en ouvrant mutex.c en apercevant des IPC
Un mutex fait parti du processus et disparait avec ...
Un sémaphore est géré par le système et ne disparait pas lorsque le processus disparait...
Donc pour moi dire que modem_run utilise un mutex est une erreur de langage, un sémaphore à 1 jeton serait plus juste ....
Mathieu,
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.