Le problème de Producteurs/Consommateurs avec les threads et les semaphores POSIX.

[issam.abdallah]

Bonjour,

Je vous propose un nouvel élément à utiliser : Le problème de Producteurs/Consommateurs avec les threads et les semaphores POSIX.

Le modèle de Producteurs/Consommateurs est un exemple classique présentant le problème du synchronisation des ressources (écran, imprimantes, mémoire ...) entre plusieurs threads.

Notre programme utilisera deux threads (producteur et consommateur) et une file d'attente (FIFO) pour partager des données (nombres entiers).

Le code source est bien commenté !

Qu'en pensez-vous ?

[Trademark]

Salut,

Alors plusieurs critiques :

• Utilisation de variables globales.
• Pas de découplage de la liste et du problème producteurs/consommateurs.
• Utilisation de sémaphore au lieu des conditions POSIX.
• Proposition d'un exercice scolaire classique, sans se pré-occuper de la ré-utilisabilité du module. Intérêt ? NULL.
• Une section critique doit être la plus courte possible et vous mettez une opération d'I/O dedans…
• Pas de libération de mémoire.

Pas la peine de déposer tous vos exercices hein

Ou alors dans la section approprié en demandant une revue de code.

[issam.abdallah]

Bonjour !
Merci pour vos remarques :

Remarque 1 : Utilisation de variables globales.
Ce programme est très simple (3 fichiers). L'utilisation de variables globales est déconseillé, c'est vrai. Mais leurs utilisation va simplifer les choses dans ce code !
Comment ?
Sans l'utilisation des variables globales, on doit faire passer ces même variables (sem1, sem2, mutex et fifo ), dans une structure, au fonctions consommer(void *param) et produire(void *param). Puis dans les deux fonctions de threads, on doit faire un cast pour convertir le type de param de void au struct !!!!!!

Remarque 2 : Pas de découplage de la liste et du problème producteurs/consommateurs.

Remarque 3 : Utilisation de sémaphore au lieu des conditions POSIX.
Where is the problem ?

Remarque 4, Remarque 5 ???????????????????

Remarque 6 :
Oops un petit free(fifo.head); a été oublié
Mon dieu, Java m'a fait oublié le C !

[Trademark]

Bonjour !
Merci pour vos remarques :

Remarque 1 : Utilisation de variables globales.
Ce programme est très simple (3 fichiers). L'utilisation de variables globales est déconseillé, c'est vrai. Mais leurs utilisation va simplifer les choses dans ce code !
Comment ?
Sans l'utilisation des variables globales, on doit faire passer ces même variables (sem1, sem2, mutex et fifo ), dans une structure, au fonctions consommer(void *param) et produire(void *param). Puis dans les deux fonctions de threads, on doit faire un cast pour convertir le type de param de void au struct !!!!!!

Les variables globales ne sont jamais la solution même dans un petit programme. Et vous semblez savoir comment vous en passer alors passez-vous en.

Remarque 2 : Pas de découplage de la liste et du problème producteurs/consommateurs.

Il y a quelque chose que vous n'avez pas compris ?

Remarque 3 : Utilisation de sémaphore au lieu des conditions POSIX.
Where is the problem ?

Ce n'est pas vraiment un problème, les sémaphores sont justes un peu dépassées. Voir article Wikipédia.

Remarque 4,

Ce que je me demande via cette remarque, c'est : quelle est l'intérêt de poster ce programme ?

Remarque 5 ???????????????????

Vous n'êtes pas sans savoir qu'une section critique est la zone de code qui est protégé par un mutex. Vous savez donc aussi que cette zone n'est accessible à tout moment que par une tâche et que si possible elle doit être le plus courte possible ! Or, une opération d'entrée/sortie comme printf est très longue à s'exécuter a l'exécution, c'est dommage vu qu'elle pourrait être en dehors. Évidemment vous pouvez avoir des problèmes d'affichage si elle est en dehors. Dans ce cas ce que vous devrez protégé par un mutex c'est, non pas l'accès à l'écriture de la console, mais l'accès a un buffer d'écriture sur la console.

[issam.abdallah]

l'intérêt de poster ce programme ?
Un des intérêts est d'ouvrir toute cette discussion

[Trademark]

Alors c'est la catégorie qui n'est pas bonne. Tu dis explicitement en début de message que c'est un élément que tu nous proposes. Enfin bref, c'est pas bien grave je suppose que tu pensais qu'il y aurait moins de critique sur ton code.