Discussion :

[n0mad]

Bonjour,

J'aurais besoin de confirmations (ou pas!) de votre part sur le threads.

J'ai donc le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
 
void thread_start()
{
        char *p = NULL;
 
        // p = ma_fonction_qui_retourne_un_char*
        printf("bonjour\n");
 
        pthread_exit(EXIT_SUCCESS);
}
 
int main()
{
        pthread_t *th;
        int i;
 
        if( (th = calloc(2, sizeof(pthread_t))) == NULL)
        {
                printf("Cannot allocate memory for threads");
                exit(EXIT_FAILURE);
        }
 
 
        for(i=0; i<2; i++)
        {
                printf("Thread %d\n", i);
 
                if( ( pthread_create(&th[i], NULL, (void *(*)())thread_start, NULL) ) == -1 )
                {
                        printf("cannot launch a thread");
                        exit(EXIT_FAILURE);
                }
        }
        //waiting threads
        for(i=0; i<2; i++)
                pthread_join(th[i], NULL);
 
        return EXIT_SUCCESS;
}

Ma question est la suivante : quelle est la portée de la variable *p dans thread_start() ? Est-ce que chaque thread à son propre p, est-ce qu'il est partagé entre les threads ? etc.
Egalement, si je fait pointer *p grace à une fonction qui renvoie un char*, est-ce que l'adresse "remplie" par la fonction est unique ou est-ce que chaque thread possède sa propre "zone mémoire pour la fonction" ?

En espérant avoir été assez clair =)

Merci

[ram-0000]

chaque thread possède sa propre pile donc la variable p n'est pas commune aux différents thread. D'ailleur un affichage de l'adresse et du contenu de la variable dans chacun des thread devrait lever le doute.

En ce qui concerne le 2eme point, j'ai pas compris la question, tu peux expliquer un peu plus s'il te plait ?

[n0mad]

Merci ram-000 pour ta réponse ça confirme ce que je pensais mais je suis sur un problème dont je n'arrive pas à me démeler donc je reprend le pb à la racine =)

J'ai modifié suivant ton conseil mon printf dans le thread_start

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
printf("bonjour : %p\n", &p);
 
//résultat :
// bonjour : 0xb76093c4
// bonjour : 0xb7e093c4

Donc la dessus on est ok : chaque thread est "cloisonné".


Ma deuxieme question est la suivante :

J'ai une fonction, mettons "f" dont le code pourrait ressembler à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
char *f()
{
    char *pf = calloc(8, sizeof(char));
    strcpy(pf, "bonjour");
    return pf;
}

bon évidemment c'est un exemple bateau, ma vraie fonction remplie "p" avec des valeurs différentes à chaque appel.

Mon problème est donc de savoir si dans l'execution du programme j'ai un et un seul pf ou autant de pf que de threads. Autrement dit, est-ce que l'appel à f() dans thread_start() ne peut-il pas poser de problème (s'il y a un seul adresse de pf) : on aura donc une sorte "d'overlapping" ou chaque thread appelerai f() et l'état de pf serait donc "incertain" étant donné que le thread 1 pourrait commencer à le remplir et avant de retourner, le thread 2 ferais la meme opération....

Exemple : si f() retourne un pointeur sur "valeur_1" par l'appel de thread 1 et f() retourne un pointeur sur "pwet_2" par l'appel de thread 2, on pourrait avoir finalement dans pf quelquechose comme "pweeur_1"

C'est pas franchement facile à expliquer =) !!


En admettant que ce fonctionnement est normal (retour de pweeur_1), comment peut-on faire pour ne pas avoir ce genre de problème ? (sans appel à des vérrous type mutex )

un " const char *f() "ou " extern char *f() " ça fait quoi ? :o)

[n0mad]

static ...uhm un truc que je ne connais pas, jvais aller voir google =)

Donc si j'ai bien compris, en l'état actuel du code, notamment pour f(), il n'y aura pas de problèmes.

J'aurais quand même une question complémentaire : que se passerait-il si *pf était déclaré en static ?

Merci

Je crains malheuresement que mon problème viens du fait que la valeur retournée est finalement déclarée en static :-s

Enfaite ma fonction f() fait appel à crypt()...Et crypt semble etre déclarée en static :'(

Uhm la j'avoue que je suis sec : je viens de regarder la déclaration de crypt dans /usr/include/crypt.h

et ya ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
extern char *crypt (__const char *__key, __const char *__salt)
     __THROW __nonnull ((1, 2));

de ce que j'en comprend, il n'y a pas de static....quelqu'un peut-il m'expliquer =)

[Médinoc]

crypt() retourne l'équivalent d'une variable static et est donc vulnérable.

Note que ce n'est pas le cas sous Windows avec Visual ou MinGW, où les fonctions comme crypt() sont isolées d'un thread à l'autre: on appelle ça du Thread-Local Storage (TLS).
Mais sous *n*x, tout est partagé.

[n0mad]

Bien ok merci médinoc c'est très clair.

Donc je souhaite toujours pouvoir faire appel à crypt() (ou similaire) dans mes threads... quelles options ais-je ?

1. Copier/Coller le source de crypt() et virer le static dans la fonction ? Ou est ce satané fichier je ne le trouve pas !
2. Utiliser un librairie de crypto autre que glibc ? Laquelle ?
3. Autre ?

[Emmanuel Delahaye]

J'ai donc le code suivant :

J'ai réécris ton code dans l'esprit 'programmation structurée', c'est plus clair...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
 
void *thread_start (void *user)
{
   char *p = NULL;
 
   /* p = ma_fonction_qui_retourne_un_char* */
   printf ("bonjour\n");
 
   return NULL;
}
 
int main (void)
{
   int ret;
   pthread_t *th = calloc (2, sizeof (pthread_t));
 
   if (th != NULL)
   {
      int i;
      ret = EXIT_SUCCESS;
      for (i = 0; ret == EXIT_SUCCESS && i < 2; i++)
      {
         printf ("Thread %d\n", i);
 
         if (pthread_create (&th[i], NULL, thread_start, NULL) == -1)
         {
            printf ("cannot launch a thread");
            ret = EXIT_FAILURE;
         }
      }
 
      /* waiting threads */
      for (i = 0; i < 2; i++)
      {
         pthread_join (th[i], NULL);
      }
 
   }
   else
   {
      printf ("Cannot allocate memory for threads");
      ret = EXIT_FAILURE;
   }
 
   return ret;
}

Ma question est la suivante : quelle est la portée de la variable *p dans thread_start() ? Est-ce que chaque thread à son propre p, est-ce qu'il est partagé entre les threads ? etc.

Un thread est une fonction. Les données locales sont strictement locales au thread et ne sont pas du tout partagées. Par contre, il y a un contexte local (pile) par thread.

Ce qui peut être commun à tous les threads est soit une variable statique du processus, soit une variable allouée dans le processus, soit une variable locale de la fonction qui a lancé le thread, à condition que celle-ci existe après le lancement (c'est le cas ici, grâce aux synchronisations par pthread_join()).

Egalement, si je fait pointer *p grace à une fonction qui renvoie un char*, est-ce que l'adresse "remplie" par la fonction est unique ou est-ce que chaque thread possède sa propre "zone mémoire pour la fonction" ?

Oui, chaque thread a son contexte local, sinon, ce serait inexploitable. Le code n'existe qu'une fois, mais les données locales (pile) sont instanciées pour chaque thread...

[n0mad]

OK merci Emmanuel pour ces précisions.

Je viens de faire un bout de code, et mon problème viens bien de la fonction crypt. En effet, les deux threads pointent tous deux sur la même adresse mémoire...

Comment puis-je faire pour éviter ce problème ?

Evidemment il y a les mutex mais dans ce cas je perds l'interet des threads ! Existe-il des librairie de crypto dédiées en C ? Puis-je "hacké" la fonction crypt() ? (je pensais a reprendre le source et simplement virer le "static" qui est le mot de mes maux :p)

D'autres idées ??

[Médinoc]

Regarde s'il existe une fonction crypt_r() (plusieurs fonctions POSIX ont une version _r qui résout le problème). Sinon, il faudra soit utiliser une bibliothèque dédiée, soit protéger les accès à crypt() par un mutex le temps du cryptage et de la création d'une copie...

[matafan]

Virer le static ne règlerait pas ton problème. En fait il l'agraverait, puisqu'alors même sans threads, crypt() serait inexploitable. Pour régler le problème il faudrait que crypt aloue la chaine retournée dynamiquement (avec malloc).

Tu peux par contre utiliser crypt_r(), qui stocke la chaine chiffrée dans un buffer passé en paramètre. Le _r veut dire "reentrant". De nombreuses fonctions non réentrantes de la libc ont une version réentrante suffixée par _r (par exemple strtok/strtok_r).

[n0mad]

Bonjour,

Merci pour vos réponses.

Effectivement un crypt_r existe. D'après le man, la signature est la suivante :
char *crypt_r(const char *key, const char *salt, struct crypt_data *data);

Je dois être un sacré boulet car je n'arrive pas à m'en sortir ! Auriez-vous des exemples d'utilisation car je n'en trouve pas.

Il semblerait que cette fonction modifie la valeur de key ? Je ne comprends pas pourquoi étant donné la signature...est-ce normal ou suis-je tout simplement un gros boulet ? (vous avez le droit de choisir l'option n°2 mais argumentez...!)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
void thread_start()
{
        char *p = NULL;
        struct crypt_data *cd;
 
        cd = malloc(sizeof(struct crypt_data *));
 
        if( cd != NULL )
        {
                cd->initialized = 0;
                while( (p = next(p)) != NULL )
                {
                        crypt_r(p,"AA",cd);
                        printf("%s - %s\n", p, cd->crypt_3_buf);
                }
        }
        pthread_exit(EXIT_SUCCESS);
}

la fonction next() me retourne "msg1" puis "msg2" puis "msg3", etc. Avec crypt() pas de problèmes, mais crypt_r me modifie mon 'p'...c'est normal docteur ? Je suis obligé de passer par une copie locale de p pour m'en sortir ?

Merci

** EDIT ** : même avec une copie local ça me change mon 'p' ! Je ne comprends rien j'ai déclaré un p2, j'ai fais le malloc qui va bien, dans p2 je fais un strcpy(p2, p); et j'appel crypt_r avec p2 et non plus 'p'....mon 'p' change qd meme...

[matafan]

C'est la zone qui est pointée par le 3 ème argument qui est modifiée. Je pense que ton p est modifié parce que tu n'alloue pas la bonne taille pour la zone pointée par cd, donc quand crypt_r écrit dedans ça déborde sur p. Il faut que tu alloues sizeof(struct crypt_data), pas sizeof(struct crypt_data *).

[Médinoc]

Ou bien, que tu mettes directement ta structure crypt_data sur la pile.

[n0mad]

Bon comment dire, l'option à choisir était bien "je suis un gros boulet" :-)

Merci a tous pour vos réponses, et mon dernier problème était bien sizeof(struct crypt_data). Reprendre le source après quelques heures de pauses, cela semble si évident... comme quoi des fois, mieux vaut faire des pauses (et demander l'avis de guru comme vous!).

Merci beaucoup en tout cas.