THREADS - utilisation de pthread.h

Marsh Posté le 25-05-2006 à 18:29:54

Bonjour,

J'ai une interface graphique (XMotif) :
En plusieurs étapes, on saisit des parametres dans la fenetre principale.
A la dernière étape, on appelle la fonction qui effectue le traitement sur la base des paramètres. Ce traitement peut durer plusieurs heures voir plusieurs jours.

Apres le lancement du traitement, il y a un bouton "STOP" dans le GUI qui doit permettre d'arreter le traitement.

Pour mettre en oeuvre tt cela, je décide d'utiliser les threads via les fonctions suivantes :

Code :

static void * traitement ( void * p_data)
{ ... }

: la tache en thread qui lancera le traitement

Code :

pthread_create( &tth, NULL, traitement, NULL);

: la création du thread

1 / Est-ce une obligation d'utiliser la fonction pthread_join ( ... ) ?
Imaginons que la fonction appelée dans le thread mette à jour une variable globale pour indiquer au GUI que le traitement est terminé. Dans ce cas je pense que l'utilisation de pthread_join n'est pas utile. Qu'en pensez-vous ?

2/ Est-ce que dans un programme C un la tache d'un thread peut voir et accéder les variables globales auxquelles accède le programme qui l'a créé ?

Message cité 2 fois
Message édité par jipo le 25-05-2006 à 18:52:45

---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)

Reply

Marsh Posté le 25-05-2006 à 18:29:54

Reply

Marsh Posté le 25-05-2006 à 19:10:18

jipo a écrit :

Pour mettre en oeuvre tt cela, je décide d'utiliser les threads via les fonctions suivantes :

Des variables globales... [:vomi]

Un peu de lecture...

http://mapage.noos.fr/emdel/pthreads.htm

Ensuite, pose des questions si (encore) nécessaire...

Message cité 1 fois
Message édité par Emmanuel Delahaye le 25-05-2006 à 19:11:21

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Reply

Marsh Posté le 25-05-2006 à 19:20:37

Merci Emmanuel,

Je pensais bien et me doutais que ce serait toi qui répondrait le premier à ce topic ...

J'avais déjà lu ta page trouvée dans un autre topic. Pour autant je ne suis pas sur des réponses aux questions que je pose ci-dessus.
Pour ce qui est des variables globales, il s'agit d'un long passif dont je ne suis pas responsable ...

Voilà donc les questiopns restent posées :jap:

---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)

Reply

Marsh Posté le 25-05-2006 à 23:54:13

De plus je me demande : est-ce qu'une variable accedeee par un thread peut bloquer un autre qui accede à la meme variable en meme temps, qd on utilise pas les mutex ?

Message cité 1 fois

---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)

Reply

Marsh Posté le 26-05-2006 à 00:00:58

jipo a écrit :

De plus je me demande : est-ce qu'une variable accedeee par un thread peut bloquer un autre qui accede à la meme variable en meme temps, qd on utilise pas les mutex ?

Non, sinon à quoi serviraient les sémaphores ?

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

Reply

Marsh Posté le 26-05-2006 à 00:18:07

Emmanuel Delahaye a écrit :

http://mapage.noos.fr/emdel/pthreads.htm

Ensuite, pose des questions si (encore) nécessaire...

Salut.
J'ai jeté un rapide coup d'oeil. C'est pas mal, mais j'ai quelques remarques:

Citation :

Les essais ont été faits sous Windows 98 avec Dev-C++ et sa bibliothèque pthread. L'ordonnanceur de Windows étant préemptif, les abérrations de fonctionnement sont claires et évidentes. Les essais réalisés sous Linux embarqué (Kernel 2.4 pour Power PC) sont moins parlants, car l'ordonnanceur n'est pas préemptif.

Je comprends pas.
Ca fait un moment que l'ordonnanceur de linux est préemptif, en tout cas le 2.4 l'était.
Ce qui a été introduit dans le 2.6, c'est la préemption en espace noyau (preemptive kernel), c'est-à-dire des appels système.

Et je vois ça aussi:

Citation :

Un caractère est une valeur numérique qui représente un glyphe visible ('A', '5', '*' etc.) ou non (CR, LF etc.). Un caractère est de type int. Cependant, sa valeur tient obligatoirement dans un type char.

Un objet de la taille d'un byte peut recevoir la valeur de n'importe quel caractère.

Un caractère est un type entier (integer) char, pas int.
La preuve, c'est qu'une chaîne de caractères est de type char [].

Par contre, une constante caractère est un entier.
C'est pour ça que sizeof('z') ne renvoie pas 1.

Citation :

Le langage C n'a à voir ni avec UNIX ni avec POSIX.

Ouais, on est pas loin du troll là.
Le C a quand même été inventé par les pères d'Unix, pour Unix. D'ailleurs la dernière partie du K&R traite des appels systèmes Unix.

Citation :

The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system.

http://cm.bell-labs.com/who/dmr/chist.html

Message édité par simple_stupid le 26-05-2006 à 14:17:15

Reply

Marsh Posté le 26-05-2006 à 02:25:45

jipo a écrit :

1 / Est-ce une obligation d'utiliser la fonction pthread_join ( ... ) ?
Imaginons que la fonction appelée dans le thread mette à jour une variable globale pour indiquer au GUI que le traitement est terminé. Dans ce cas je pense que l'utilisation de pthread_join n'est pas utile. Qu'en pensez-vous ?

NON : dans mon cas la seule procedure principale crée un seul thread pour gerer le traitement lourd pendant que la procedure principale continue à gerer le GUI . l'utilisation de pthread_join bloquerait le GUI sinon ...
CONFIRMER ?

jipo a écrit :

2/ Est-ce que dans un programme C un la tache d'un thread peut voir et accéder les variables globales auxquelles accède le programme qui l'a créé ?

OUI ..

Mes questions : mes reponses ... c'est tellement plus simple ... [:audi]

Message cité 1 fois
Message édité par jipo le 26-05-2006 à 02:26:32

---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)

Reply

Marsh Posté le 26-05-2006 à 09:29:00

jipo a écrit :

NON : dans mon cas la seule procedure principale crée un seul thread pour gerer le traitement lourd pendant que la procedure principale continue à gerer le GUI . l'utilisation de pthread_join bloquerait le GUI sinon ...
CONFIRMER ?

http://www.opengroup.org/pubs/onli [...] _join.html

C'est un appel bloquant.

Reply

THREADS - utilisation de pthread.h

Sujets relatifs:

Leave a Replay