Pile et thread

Bonjour,

J'ai un système qui me lit des données et qui doit faire un traitement dessus. Ce que j'ai pensé faire, c'est un thread qui s'occupe des la lecture et un thread qui s'occupe du traitement. Comme le traitement peut prendre du temps (Plus que la lecture), j'ai pensé faire une pile FIFO.
Le principe est simple, le thread de lecture ajoute les données au dessus de la pile et le thread de traitement retire les données au fond de la pile.

Un petit schéma :

Code:

---

1 2 3 4 5 6 7 8

(Lecture des données) -> [data 6] [data 5] - [data 4] | [data 3] > PILE [data 2] | [data 1] - [data 0] -> (traitement des données)

---

(les données sont des blocs d'une 50aine d'octet)

Ainsi, les threads ne doivent pas être synchroniser et la lecture ne doit pas attendre la fin du traitement. Le traitement lui prend des données temps qu'il y en a.

Je pensais mettre aussi un verrou sur la pile et sur les données (Un unité de données peut-être verouiller, ou bien toute la pile carrément). Le problème est que le verrou n'est qu'une simple variable (ma pile est mes unités de données sont des structures) et je ne sais pas si on peut se trouver dans la situation suivant : Les deux threads veulent verouiller la pile en même temps, que se passera-t-il ?

Et je me demande s'il y a d'autre solutions possibles pour faire ça, la mienne n'est sûrement pas la meilleur !

Merci.

T.

Quel OS car dans ce cas de figure cela peut avoir sont importances.

Plutot qu'une pile que tu va devoir gérer utilise les mecanisme present sur l'OS :
UNIX: les messages queues font cela tres bien (ipcs)
WINDOWS : les mailslot font l'equivalent

l'interrer est que le mecanisme te permettra de ne pas gérer un quelquonque gestion de blocage ou de synchronisation mais juste la presence ou nom de message dans la file :)

Actuellement l'OS est Windows, mais un portage vers UNIX est envisagé, donc j'aimerais garder une indépendance maximale au niveau de l'OS, ce qui n'est pas toujours le cas. Mais moins il y a de code à modifier pour le portage, mieux c'est !

le probleme c'est que ces mecanisme sont differents entre les 2 OS.
Le principe reste le meme (les messages queue sous windows sont imbuvables et non portable pas plus que les mailsslot d'ailleur).
En isolant les fonctions de creation/lecture/ecriture des queues le code restant devrait etre portable, enfin si y a pas appelle au MFC, ni au GUI ....ni au thread d'ailleurs :(

Bon pour les threads j'utilise la glib et gtk pour l'interface, donc il ne devrait pas y avoir de problèmes, mais pour le principe ci-dessus, je pense que je peux prendre le temps de faire un système et à la limite je peux utiliser les mutex pour être sur de ne pas avoir de problème au niveau d'accès des données.

Je pense que c'est une bonne solution, non ?

T.

oui bien sur mais l'usage des queue sous unix ou des mailslot sous windows et asses simple, surement plus simple que les mutex si tu a + de 2 threads

Ok, je vais regarder ça.

Merci beaucoup.

T.