Discussion :

[sybe30]

Bonjour,

Je cherche à faire communiquer 2 threads en C#.
Pour cela j'ai voulu mettre en place un pipe. Un thread qui écrit dedans (bloquant si plein) et un autre qui lit (non bloquant si vide). En général sur les systèmes que je connais c'est soit tout bloquant soit rien bloquant. Donc je m'en sors en choisissant le mode bloquant et en interrogeant "est-ce qu'il y a qqch à lire" avant la fonction de lecture. Mais voila les systèmes que je connais c'est pas Windows et pas C# (je viens de l'embarqué). Donc je me tourne vers vous pour progresser sur ces nouveaux chemins.

Pour le moment j'ai un code qui ressemble à :

Pour la création dans un premier thread

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
System.IO.Pipes.NamedPipeServerStream pipeServer = new System.IO.Pipes.NamedPipeServerStream("BackToFrontData", 
                                                        PipeDirection.InOut, 
                                                        1, 
                                                        PipeTransmissionMode.Byte, 
                                                        PipeOptions.Asynchronous, 
                                                        100, 
                                                        100);
....
pipeServer.WaitForConnection();
.....
 
tmp[0] = (Byte)pipeServer.ReadByte(); // c'est ce read qui ne doit pas être bloquant
.....

et dans le second thread :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
System.IO.Pipes.NamedPipeClientStream pipeClient = new System.IO.Pipes.NamedPipeClientStream("BackToFrontData");
...
pipeClient.Write(data, 0, 2);  // c'est ce write qui doit attendre si le pipe est plein
.....
.....

Voila je débute en C#. Avant j'ai un peu développé en C sous windows et je me souviens qu'avec les API WIN32 j'avais des options et des API qui me permettaient de le faire. Mais il faut évoluer de temps en temps donc je suis passé à C# et la je suis bloqué.

Merci pour votre aide.

[sybe30]

Rien ? Personne ?

Bon et bien dommage.
J'attends encore un peu avec de cloturer le thread.

Merci

[GuruuMeditation]

Tu dois utiliser la forme asynchrone BeginRead() si tu veux du non bloquant.

[sybe30]

Bonjour,

Merci pour cette réponse et j'utiliserai ce work-arround si je trouve pas mieux.

Mais n'existe t'il pas un moyen de savoir combien d'octets sont pret à lire dans le pipe ? (les methodes .length et .position) me levent des exceptions.

Cordialement

[tomlev]

BeginRead est effectivement non-bloquant, mais l'opération ne va pas pour autant se terminer immédiatement s'il n'y a rien à lire... le callback ne sera appelé que quand quelque chose aura été lu (ou s'il y a un timeout)

Je suis pas sûr, mais je pense que la propriété InBufferSize te donne le nombre d'octets à lire.

[sybe30]

Bonjour,

Il me semble que je l'ai essayé sans succés mais je vais m'en assurer.

Merci.

[sybe30]

Bonjour,

Je confirme. Ces attributs InBufferSize et OutBufferSize retournent la taille de ces buffers. Donc les tailles avec lesquelles j'ai créé le pipe. C'est qu'il me faudrait (bien que j'ai pas compris pourquoi il y a 2 buffers) c'est connaitre le taux de remplissage, le nombre d'octet qui y a été écrit dedans.

Merci

[antoine.debyser]

Bonjour,

En .Net on fait l'inverse, Read bloquant, Write non bloquant. A ma connaissance il n'y a pas d'option pour inverser cela.
Donc pour rendre le Read non bloquant, on peut utiliser un thread qui utilisera le Read bloquant, et empilera les donné lu. Du coup la lecture non bloquante consiste a dépiler.
Pour rendre le transformer le Write bloquant, en comparant la propriete "Position" avec la propriete "OutBufferSize", on devrait pouvoir determiner si on doit attendre.

PS: En C++ on utilise ReadFile pour lire sur le NamedPipe, et ce "read" est bloquant. Dans quel cas avais tu un read non bloquant?

[sybe30]

Bonjour,

quand j'utilise .position j'ai une exception. Donc je ne peut pas l'utiliser.

Sinon j'ai un thread qui reçoit des infos (via série, USB, ou autre) les traite et les empiles dans le pipe pour le thread d'interface qui dépile et affiche des choses relative à ce qu'il a lu. Si le read est bloquant l'interface est figée. Par défaut le seul le thread qui instancie un contrôle doit y accéder. Je sais que l'on peut contourner (CheckForIllegalCrossThreadCalls = false) cette contrainte mais c'est pas le mieux à faire. Je voudrais rester propre.

Le read (par exemple sur port série) n'est pas bloquant il peut sortir en timeout. Le pipe ne semble pas gérer le timeout non plus.

Comment puis-je faire ? SVP

Cordialement

[sybe30]

Bon alors, sans regret, je ferme le thread sans solution ?

[Graffito]

Je cherche à faire communiquer 2 threads en C#.
Pour cela j'ai voulu mettre en place un pipe.

Pourquoi ne pas simplement utiliser une classe Queue et des lock?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// ================  initialisations ================  
Queue<string> myQueue = new Queue<string>(); 
int maxQueueCount=1000 ;
...
// ================ ecriture bloquante ================  
string stringToSend = "xxx" ;
bool QueueFull = true ;
while(QueueFull)
{
  lock(myQueue) 
  { 
    QueueFull=myQueue.Count>=maxQueueCount ;
    if (!QueueFull) myQueue.Enqueue(stringToSend);
  }
  if (QueueFull) System.threading.thread.Sleep(100) ; // attendre 100 ms (par exemple) avant de réessayer
}

// ================ lecture non bloquante  ================  
string stringReceived="" ;
bool MessagePresent=false ;
lock(myQueue) 
{
   MessagePresent=myQueue.Count>0 ;
   if (MessagePresent) stringReceived=myQueue.Dequeue();
 }
 if (MessagePresent)  ... // traitement de  stringReceived

On peut évidement remplacer les <string> par des objets adaptés au passage d'info.

[sybe30]

Bonjour,

J'ai pas utilisé les message queue + lock parceque je pensais que c'etait pile poil ce que faisait un pipe.

Mais je vais creuser sur ce nouvel axe. Merci

[tomlev]

C'est vrai que sur le moment j'ai pas pensé à questionner l'utilisation d'un pipe, mais pour une communication entre des threads dans le même process, c'est vraiment se compliquer la vie pour rien. C'est surtout utile pour la communication interprocess...

[sybe30]

Bonjour,

Je suis désolé mais je comprends pas bien ta réponse. C'est plus compliqué un pipe que des lock + message queue ? ou l'inverse ?

Merci

[tomlev]

Je suis désolé mais je comprends pas bien ta réponse. C'est plus compliqué un pipe que des lock + message queue ? ou l'inverse ?

Un pipe est plus compliqué

[sybe30]

Merci pour tout et à vous tous.

Sur le site de MSDN on vient de me parler de cette classe : ConcurrentQueue<T> Class

Je vais donc m'y pencher dessus.

Ce thread a, je pense, assez duré je vais le cloturer.