Discussion :

[silenteagle]

Bonjours,
J'ai un thread qui exécute ceci :

Edition : ajout du code

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
void *task_write_in_buffer (void *p)
{
    struct data *p_data = p;
    struct shared *psh = p_data->psh;
    sFIFO *pTempfifo = psh->pfifo;
    char buff[40];
    int i = 0;
 
    if(p != NULL )
    {
        while(1)
        {
            sprintf(buff,"%s : %d\r\n", p_data->sid,i);
 
            pthread_mutex_lock (&psh->mut);
 
                fifoenter(pTempfifo,buff);
 
            pthread_cond_signal (&psh->synchro);
            pthread_mutex_unlock (&psh->mut);
 
            i++;
 
            msleep (500);
        }
    }
    return NULL;
}
        }

J'ai une fifo partagée entre plusieurs threads, celui ci dessus qui y ajoute une chaîne de caractère.
Et un autre qui dépile et affiche le contenue de la pile.

Je me suis rendu compte que si je crée deux thread qui exécute le code ci-dessus, la variable "i" est partagé entre eux

Comment ce fait t'il que i soit partagé entre les deux thread et comment ce fait t'il qu'il n'est pas était décrémenté (cf ci-dessous en vert) ?

Sortie du thread qui depile la fifo :
task A : 1
Task C : 2
Task C : 3
task A : 4
Task C : 5
task A : 6
Task C : 7
Task C : 7
task A : 8
Task C : 9
Task C : 10

Merci d'éclairer ma lanterne

[Neckara]

Bonjour,

Il est difficile de répondre alors qu'on ne sait pas comment tu as déclaré i ni même comment tu l'as transmis à la fonction qui effectue le traitement.

Mais je suppose que i est une variable globale ?

[Metalman]

Je rajouterais juste à la remarque et aux questions de Neckara : n'oublie pas que les threads travaillent "avec" le processus dans le même AS !
Du coup les variables globales et la mémoire sont partagées !

[silenteagle]

Ah oui ^^
J'avais mit le minimum de code pour pas surcharger le poste

i est une variable locale, c'est bien là le problème.

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
void *task_write_in_buffer (void *p)
{
    struct data *p_data = p;
    struct shared *psh = p_data->psh;
    sFIFO *pTempfifo = psh->pfifo;
    char buff[40];
    int i = 0;
 
    if(p != NULL )
    {
        while(1)
        {
            sprintf(buff,"%s : %d\r\n", p_data->sid,i);
 
            pthread_mutex_lock (&psh->mut);
 
                fifoenter(pTempfifo,buff);
 
            pthread_cond_signal (&psh->synchro);
            pthread_mutex_unlock (&psh->mut);
 
            i++;
 
            msleep (500);
        }
    }
    return NULL;
}

[deletme]

Salut,

Après une lecture rapide du code, ta variable i est utilisée hors de la zone critique, donc potentiellement, les deux threads peuvent y accéder "simultanément". Essayes en passant le i++ avant de libérer le sémaphore.

Cdlt, dM

[Bktero]

Je suis étonné du comportement. La variable i est une variable locale non statique donc j'aurais tendance à penser que chaque thread en possède sa propre instance.

Ton code ne permet pas de reproduire le problème, ce serait gentil d'en fourni un.

Perso, j'ai essayé de reproduire le soucis avec le code suivant mais il ne reproduit rien...

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
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <windows.h>
 
 
#include "pthread.h"
 
static pthread_mutex_t mutex_screen = PTHREAD_MUTEX_INITIALIZER;
 
void *task(void *p)
{
    int i = 0;
 
    while(1)
    {
        pthread_mutex_lock(&mutex_screen);
        printf("%s = %d\n", p, i);
        pthread_mutex_unlock(&mutex_screen);
        i++;
        Sleep(1000);
    }
    return NULL;
}
int main(void)
{
    pthread_t thread_1;
    pthread_t thread_2;
 
    pthread_create(&thread_1, NULL, task, (void*)"T1");
    pthread_create(&thread_2, NULL, task, (void*)"T2");
 
    pthread_join(thread_1, NULL);
    pthread_join(thread_2, NULL);
    return 0;
}

[dahtah]

Je suis étonné du comportement. La variable i est une variable locale non statique donc j'aurais tendance à penser que chaque thread en possède sa propre instance.

Oui, c'est exact. Chaque thread dispose de sa propre stack, seule la "heap", les librairies partagees et les zones statiques (.text, .rodata, ...) sont partagees entre le parent et les thread enfants. Ici i est declaree sur la "stack", donc n'est accessible qu'au thread local.

J'ai regarde tres rapidement, mais pthread_cond_signal (&psh->synchro) doit se placer apres le realease de la mutex. Car pthread_cond_wait() dans le thread concommant ta FIFO va relacher la mutex. Du coup ton thread consommateur va relacher la mutex lockee par le thread producteur. C'est un comportement indefini normallement (seul un thread ayant locke la mutex peut la relacher).

Je sais pas si ton probleme vient de la, mais ca enleve deja un probleme potentiel.

[silenteagle]

J'ai regarde tres rapidement, mais pthread_cond_signal (&psh->synchro) doit se placer apres le realease de la mutex. Car pthread_cond_wait() dans le thread concommant ta FIFO va relacher la mutex. Du coup ton thread consommateur va relacher la mutex lockee par le thread producteur. C'est un comportement indefini normalement (seul un thread ayant locke la mutex peut la relacher).

Je sais pas si ton problème vient de la, mais ca enleve deja un problème potentiel.

Étrange, sur les tuto de Franck Hecht et emmanuel-delahaye
http://franckh.developpez.com/tutoriels/posix/pthreads/
http://emmanuel-delahaye.developpez....-threads-c/#LV

ainsi que dans le manuel de référence ecos (l'os embarqué que j'utilise)
http://ecos.sourceware.org/docs-2.0/...variables.html

Tous indique qu'il faut envoyer le signal puis relacher le mutex

[dahtah]

Tous indique qu'il faut envoyer le signal puis relacher le mutex

Je n'ai pas verifie les sources que tu proposes, mais j'ai verifie dans "The Linux Programming Interface" de Michael Kerrisk (ma bible ) , le relachement de la variable conditionnelle se fait bien apres l'unlock:

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
 
The code in the producer threads is the same as before, except that we add a call to
pthread_cond_signal():
s = pthread_mutex_lock(&mtx);
if (s != 0)
    errExitEN(s, "pthread_mutex_lock");
    avail++;	/* Let consumer know another unit is available */
s = pthread_mutex_unlock(&mtx);
if (s != 0)
    errExitEN(s, "pthread_mutex_unlock");
s = pthread_cond_signal(&cond);	/* Wake sleeping consumer */
if (s != 0)
    errExitEN(s, "pthread_cond_signal");
 
Before considering the code of the consumer, we need to explain pthread_cond_wait() in greater detail. We noted earlier that a condition variable always has an associated mutex. Both of these objects are passed as arguments to pthread_cond_wait(), which performs the following steps:
    * unlock the mutex specified by mutex;
    * block the calling thread until another thread signals the condition variable cond; and
    * relock mutex.
 
The pthread_cond_wait() function is designed to perform these steps because, normally, we access a shared variable in the following manner:
s = pthread_mutex_lock(&mtx); if (s != 0)
    errExitEN(s, "pthread_mutex_lock");
while (/* Check that shared variable is not in state we want */)
    pthread_cond_wait(&cond, &mtx);
/* Now shared variable is in desired state; do some work */
s = pthread_mutex_unlock(&mtx); if (s != 0)
    errExitEN(s, "pthread_mutex_unlock");

Si Kerrisk decrit bien ce que fait pthread_cond_wait(), mettre pthread_cond_signal() avant le release du lock provoque un effet de bord decrit dans mon poste precedent.

Je sais pas ce qui est exact ici, mais je n'ai jamais eu de soucis avec le code precedent.
Je ne dis pas que c'est le probleme avec ton code cependant, et j'espere que je t'envoie pas sur la mauvaise route...

[deletme]

Salut,

Possèdes tu le code de fifoenter ? Parce qu'à première vue, l'affichage

Code :

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

1
2
3
4
5
6
7
8
9
10
11
task A : 1
Task C : 2
Task C : 3
task A : 4
Task C : 5
task A : 6
Task C : 7
Task C : 7
task A : 8
Task C : 9
Task C : 10

devrait commencer à 0 non ?

[silenteagle]

le voici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int fifoenter(sFIFO * this, void *next)
{
    if (this->Ffc == this->Max)
    {
        return (0);
    }
    else
    {
        this->table[this->Ecr] = next;
        this->Ffc++;
        this->Ecr = (this->Ecr + 1) % this->Max;
        return (1);
    }
}

[diogene]

Code :

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

this->table[this->Ecr] = next;

Ceci va stocker dans la fifo l'adresse du tableau buff de task_write_in_buffer() et non pas le contenu. Autrement dit, tous les éléments dans la fifo font référence au même message : le dernier qui a été écrit dans le buff. Le thread de lecture affiche toujours le dernier message qui a été mis dans buff et qui dépend du moment où il est lu.

C'est pourquoi, on ne trouve pas l'affichage de i==0 : Le thead A a écrit dans son buff "task A : 0" puis "task A : 1" et à ce moment tous les éléments du fifo qui ont été écrits font référence à "task A : 1" et le thread de lecture a affiché le premier élément de la fifo qui fait référence (comme le deuxième) à "task A : 1" .

C'est aussi pourquoi, on trouve deux fois "Task C : 7" : il suffit que le thread de lecture lise deux fois avant qu'une nouvelle écrirure soit faite dans le buff du thread C