Discussion :

[nanosoft]

Bonjour,

J'utilise un programme principal qui lance un seul thread.
Le programme principal et le thread se déroulent ensuite en parallèle.

Ma question est la suivante :
Est-ce que je peux utiliser un mutex pour définir une zone critique (délimitée de pthread_mutex_lock jusqu'à pthread_mutex_unlock ) à la fois dans le programme principal et dans le thread ?
Le but, classiquement, est que le programme principal et le thread n'accèdent pas en même temps à des variables partagées.
Mais est-ce que ceci fonctionne bien entre 1 thread et le programme principal ou est-ce que le principe n'est possible que entre 2 threads ?

Merci pour votre réponse.

[Bktero]

Le "programme principal" n'est pas simplement "le premier thread" créé ?

[nanosoft]

Habituellement (du moins dans les exemples que j'ai vus), "le programme principal" lance plusieurs threads et ne fait plus rien : il attend simplement que les threads se terminent : pthread_join().
Dans mon cas : le programme lance un thread unique et continue ensuite en boucle pendant la vie du thread.
Mais c'est peut être un problème de vocabulaire : est-ce que l'on appelle aussi un thread le programme principal (celui qui démarre avec la fonction main) ?
Vocabulaire ou pas, je voudrais savoir si les mutex fonctionnent bien efficacement entre les 2 exécutions tel que décrit ?

[Bktero]

Je viens de regarder vite fait sur Internet. Je vois que ça parle de "thread principal" pour décrire le contexte où s'exécute main(). Et j'ai aussi vu un code où le main() travaille avec un mutex qu'il partage avec un 2nd thread. Voir : http://stackoverflow.com/questions/5...ferent-threads

[nanosoft]

Merci pour ton aide, c'est curieux dans le dernier listing du lien : le mutex est locké avant même que le thread ne soit créé !

Bon, d'après toi il n'y a pas de souci alors ?

[o_Nejma]

Bonjour,

Mais est-ce que ceci fonctionne bien entre 1 thread et le programme principal ou est-ce que le principe n'est possible que entre 2 threads ?

Bonjour,

Je pense qu'il vaut mieux garder le programme principal comme une tache qui ne sert qu'à lancer tes taches, et rien d'autres, après au lieu d'ajouter du code applicatif dans le programme principal, tu crée un deuxième threads ou tu y ajoutes ce que le programme principal fait avec les ressources partagées...Et comme ça la protection des variables sera gérée entre les deux threads.

Voilà c'est juste une proposition concernant le design

cordialement,

[dinobogan]

Le programme principal est un thread, au même titre que n'importe quel autre thread.
Utiliser un mutex entre un thread et le thread principal ne pose aucun problème.

[nanosoft]

Utiliser un mutex entre un thread et le thread principal ne pose aucun problème.

Bon voila qui me rassure, merci dinobogan !

Voilà c'est juste une proposition concernant le design

Oui o.meryem, c'était l'architecture de mon premier design mais j'ai changé pour des questions de priorité entre threads.
Dans mes essais j'ai une meilleure réactivité sur le thread principal, mais je ne suis pas sur de ma gestion des priorités, je vais faire des essais complémentaires.

Merci à tous.