Multithreading: lecture/écriture dans un tube

Question

J'écris des données dans un tube - peut-être beaucoup de données et à des intervalles aléatoires. Comment lire les données du tuyau?

Est-ce ok:

• dans le fil principal (processus en cours) créer deux autres fils (2, 3)
• le deuxième fil écrit parfois à la canalisation (et rincer-es le tuyau?)
• le 3ème fil a boucle infinie qui lit le tube (et dort pendant un certain temps)

Est-ce correct jusqu'à présent?

Maintenant, il y a quelques chose que je ne comprends pas:

• dois-je verrouiller (mutex?) La conduite à l'écriture? IIRC, en écrivant à pipe et son tampon est plein, l'extrémité d'écriture bloquera jusqu'à ce que je lise les données déjà écrites, n'est-ce pas? Comment vérifier les données de lecture dans le tuyau, pas trop souvent, pas trop rarement? Alors que le deuxième thread ne bloque pas? Y a-t-il quelque chose comme select pour les tuyaux?
• Il est possible de régler le tuyau sans tampon ou je dois le rincer régulièrement - lequel est le meilleur?
• Dois-je créer un thread de plus, juste pour rincer le tuyau après l'écriture? Parce que les blocs de rinçage aussi bien, quand le tampon est plein, non? Je ne veux pas le 1er et le 2ème fil pour bloquer ....

[Modifier] Désolé, je pensais que la question est la plate-forme agnostique, mais juste au cas où: Je regarde cette perspective de Win32 , peut-être MinGW C ...

Answer 1

Je ne réponds pas à toutes vos questions ici parce qu'il ya beaucoup d'entre eux, mais en réponse à:

dois-je verrouiller le tuyau (mutex?) sur écrire?

La réponse à cette question est la plate-forme spécifique, mais dans la plupart des cas, je dirais oui . Il s'agit de savoir si les opérations d'écriture/lecture sur le tube sont atomiques. Si le lire ou écriture opération est non-atomique (plus probablement l'écriture), alors vous aurez besoin de verrouiller le tuyau en écriture et en lecture pour éviter les conditions de course.

Par exemple, permet de dire une écriture à la conduite compile jusqu'à 2 instructions dans le code de la machine:

INSTRUCTION 1 
INSTRUCTION 2 

Disons que vous obtenez un changement de contexte de fil entre ces 2 instructions et vos tentatives de fil de lecture à lire le tuyau qui est dans un état intermédiaire. Cela peut entraîner un plantage ou (pire) une altération des données qui peut souvent se manifester lors d'un plantage ailleurs dans le code. Cela se produit souvent à la suite d'une condition de concurrence qui sont souvent non déterministes et difficiles à diagnostiquer ou à reproduire.

En général, sauf si vous pouvez garantir que tous les threads accèderont à la ressource partagée à l'aide d'un jeu d'instructions atomiques, vous devez utiliser pour utiliser des mutex ou des sections critiques.