Les semaphores
3 participants
Page 1 sur 1
Les semaphores
Bonjour,
Les sémaphores c'est le bien, il existe une tonne de références à ce sujet (cf. http://man.developpez.com/man3/sem_init.3thr.php).
Mais très peu d'exemples d'utilisations. Connaissez vous un quelconque exemple de code mettant en pratique cette base incontournable ?
Si le manuel est assez précis, sa mise en œuvre est une autre paire de manche.
merci d'avance.
Les sémaphores c'est le bien, il existe une tonne de références à ce sujet (cf. http://man.developpez.com/man3/sem_init.3thr.php).
Mais très peu d'exemples d'utilisations. Connaissez vous un quelconque exemple de code mettant en pratique cette base incontournable ?
Si le manuel est assez précis, sa mise en œuvre est une autre paire de manche.
merci d'avance.
Re: Les semaphores
Si tu parles des sémaphores des pthreads, j'ai donné quelques exemples ici :tim a écrit:Les sémaphores c'est le bien, il existe une tonne de références à ce sujet (cf. http://man.developpez.com/man3/sem_init.3thr.php).
Mais très peu d'exemples d'utilisations. Connaissez vous un quelconque exemple de code mettant en pratique cette base incontournable ?
Si le manuel est assez précis, sa mise en œuvre est une autre paire de manche.
http://mapage.noos.fr/emdel/pthreads.htm
Re: Les semaphores
En fait je parlais des sémaphores dans son utilisation générale.
Par exemple dans le cas de l'accès d'une ressource quelconque entre différents processus. ( l'accès à la mémoire, pour être plus précis, une allocation dynamique via un malloc et sa libération par un free() ).
Dans mon cas, je me disais que ça aurait été bien de pouvoir gérer cette attribution de façon séquentielle ( j'ai remarqué que le fait de lancer plusieurs applications utilisant un malloc pouvait entrainer un conflit dans la mémoire).
Ce qui me fait peur dans le man du malloc :
Par exemple dans le cas de l'accès d'une ressource quelconque entre différents processus. ( l'accès à la mémoire, pour être plus précis, une allocation dynamique via un malloc et sa libération par un free() ).
Dans mon cas, je me disais que ça aurait été bien de pouvoir gérer cette attribution de façon séquentielle ( j'ai remarqué que le fait de lancer plusieurs applications utilisant un malloc pouvait entrainer un conflit dans la mémoire).
Ce qui me fait peur dans le man du malloc :
ça lui arrive de tuer mon application et comme elle tourne comme serveur, cela me tue mes clients aussi :) D'où un petit sémaphore pour contrôler tout ça :)Ceci signifie que lorsque malloc () renvoie une valeur non-NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l'infâme exterminateur de gestion mémoire.
Re: Les semaphores
Si il s'agit de différents processus, à ma connaissance, il n'y a pas de problèmes de concurrence liés à malloc(), car, selon le système, soit chaque processus gère son espace de mémoire allouée, soit il en gère déjà l'accès concurrent.tim a écrit:En fait je parlais des sémaphores dans son utilisation générale.
Par exemple dans le cas de l'accès d'une ressource quelconque entre différents processus.
Je pencherais pour un problème d'utilisation de la mémoire, mais pas de création. Quand au free(), il doit évidemment ne pas faire trop tôt. Montre le code qui a un problème.( j'ai remarqué que le fait de lancer plusieurs applications utilisant un malloc pouvait entrainer un conflit dans la mémoire).
Tu parles probablement de GNU/Linux. Oui, ce problème est connu. Tant que la mémoire allouée n'a pas été utilisée, elle n'est pas véritablement allouée. Ca se règle en faisant suivre l'allocation par un accès en écriture (initialisation, ce qui n'est pas rare dans un programme !). Ce n'est pas une parade absolue, mais généralement, ça fonctionne...
Ce qui me fait peur dans le man du malloc :ça lui arrive de tuer mon application et comme elle tourne comme serveur, cela me tue mes clients aussi :) D'où un petit sémaphore pour contrôler tout ça :)Ceci signifie que lorsque malloc () renvoie une valeur non-NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l'infâme exterminateur de gestion mémoire.
Plus de détails sur un forum spécialisé GNU/Linux. Le langage C ne décrit pas les mécanismes d'implémentation.
Re: Les semaphores
Merci pour ce début de réponse,
J'aurais du être plus précis. En fait, j'ai une application en C, qui fait office de serveur ( socket entre autre). Elle tourne actuellement sur ma machine, en test . Sur cette même machine, je décide de lancer de façon très rapprochée, plusieurs clients (en flash).
Un cas d'utilisation de ce client peut être, lorsqu'il se connecte , de récupérer la liste de toutes les personnes déjà présentes sur le serveur ( stockage dans un tableau ). Je fabrique donc une chaine de caractères dynamique ( voir mon post sur malloc), elle se présente sous la forme "lesConnectés=toto=titi=tutu=.." que j'envoie par un send() et que je libère avec un free().
Suite à ce rajout, lors de tests poussés, j'ai pu remarquer qu'il pouvait y avoir un conflit dans la gestion de la mémoire, je me suis dis que cela était peut être dû à la concurrence des processus sur la ressource critique que pouvait représenter le malloc.
J'ai pensé que l'utilisation de sémaphores pouvait être une solution afin de contrôler la chose.
J'aurais du être plus précis. En fait, j'ai une application en C, qui fait office de serveur ( socket entre autre). Elle tourne actuellement sur ma machine, en test . Sur cette même machine, je décide de lancer de façon très rapprochée, plusieurs clients (en flash).
Un cas d'utilisation de ce client peut être, lorsqu'il se connecte , de récupérer la liste de toutes les personnes déjà présentes sur le serveur ( stockage dans un tableau ). Je fabrique donc une chaine de caractères dynamique ( voir mon post sur malloc), elle se présente sous la forme "lesConnectés=toto=titi=tutu=.." que j'envoie par un send() et que je libère avec un free().
Suite à ce rajout, lors de tests poussés, j'ai pu remarquer qu'il pouvait y avoir un conflit dans la gestion de la mémoire, je me suis dis que cela était peut être dû à la concurrence des processus sur la ressource critique que pouvait représenter le malloc.
J'ai pensé que l'utilisation de sémaphores pouvait être une solution afin de contrôler la chose.
Re: Les semaphores
Que signifie 'en flash' ?tim a écrit:J'aurais du être plus précis. En fait, j'ai une application en C, qui fait office de serveur ( socket entre autre). Elle tourne actuellement sur ma machine, en test . Sur cette même machine, je décide de lancer de façon très rapprochée, plusieurs clients (en flash).
Pseudo-code :
Un cas d'utilisation de ce client peut être, lorsqu'il se connecte , de récupérer la liste de toutes les personnes déjà présentes sur le serveur ( stockage dans un tableau ). Je fabrique donc une chaine de caractères dynamique ( voir mon post sur malloc), elle se présente sous la forme "lesConnectés=toto=titi=tutu=.." que j'envoie par un send() et que je libère avec un free().
- Code:
char *s = malloc()
if (s != NULL)
{
init(s)
send(s)
free (s);
Je préfère mettre le code en cause, avant de dire que c'est le système ! Poste ton code, il est probablement buggé.
Suite à ce rajout, lors de tests poussés, j'ai pu remarquer qu'il pouvait y avoir un conflit dans la gestion de la mémoire, je me suis dis que cela était peut être dû à la concurrence des processus sur la ressource critique que pouvait représenter le malloc.
C'est peu probable. La système fait déjà ce qu'il faut.J'ai pensé que l'utilisation de sémaphores pouvait être une solution afin de contrôler la chose.
Re: Les semaphores
Il y a eu X versions et tentatives de codes pour cette partie, la solution ci-dessous est la seule qui puisse m'amener un semblant de solution.
En fait, elle marche (c'est l'essentiel), même après quelques tests poussés.
J'avoue abuser des largeurs du langage C, notamment avec le malloc (char*) et le realloc.
PS: J'entends par Flash, le fait d'avoir réalisé un petit client en flash, pour changer du telnet
En fait, elle marche (c'est l'essentiel), même après quelques tests poussés.
- Code:
rcvall = (char*)malloc(n*sizeof(char*));
if(rcvall!=NULL)
{
strcpy(rcvall,"listedesconnectes=");
for (i2 = 0; i2 < n; i2++)
{
//Ici je change de client
// blabla
if (sock != INVALID_SOCKET)
{
//realloc(rcvall,n*sizeof(rcvall)+strlen(rcvall)+2);
realloc(rcvall,n*sizeof(char*));
//J'avais une préférence pour la solution commentée
itoa(sock, psock, 10);
strcat(rcvall,psock);
strcat(rcvall,"/");
strcat(rcvall,pseudo);
strcat(rcvall,"=");
}
else
{
puts ("Socket non valide");
}
}
send ();
free(rcvall);
rcvall=NULL;
}
J'avoue abuser des largeurs du langage C, notamment avec le malloc (char*) et le realloc.
PS: J'entends par Flash, le fait d'avoir réalisé un petit client en flash, pour changer du telnet
Re: Les semaphores
tim a écrit:Il y a eu X versions et tentatives de codes pour cette partie, la solution ci-dessous est la seule qui puisse m'amener un semblant de solution.
En fait, elle marche (c'est l'essentiel), même après quelques tests poussés.
- Code:
rcvall = (char*)malloc(n*sizeof(char*));
- Combien vaut n ?
- A quoi sert le cast ?
- Pourquoi sizeof (char*) ? Le cast est faux ?
Je rappelle la méthode canonique :
- Code:
T *p = malloc(n * sizeof *p);
- Code:
char* rcvall = malloc (n*sizeof *rcvall);
realloc() ne fonctionne pas du tout comme ça. A lire d'urgence :
- Code:
//realloc(rcvall,n*sizeof(rcvall)+strlen(rcvall)+2);
realloc(rcvall,n*sizeof(char*));
http://mapage.noos.fr/emdel/notes.htm#realloc
et corriger le code en conséquence.
Re: Les semaphores
Il me semble que la fonction itoa n'est pas portable. Enfin c'est juste un petit détail dans l'application
flo- Bavard
- Messages : 11
Date d'inscription : 04/06/2008
Page 1 sur 1
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum
|
|