NamedPipe bloquant ET non

Version imprimable

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:

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:

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.

08/10/2012, 09h35
sybe30

Rien ? Personne ?

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

Merci
08/10/2012, 13h55
GuruuMeditation

Tu dois utiliser la forme asynchrone BeginRead() si tu veux du non bloquant.
08/10/2012, 16h20
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
08/10/2012, 18h22
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.
09/10/2012, 09h23
sybe30

Bonjour,

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

Merci.
09/10/2012, 09h36
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
09/10/2012, 11h28
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?
09/10/2012, 13h15
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
11/10/2012, 21h02
sybe30

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

Citation:

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:

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.

12/10/2012, 16h14
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
12/10/2012, 16h36
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...
15/10/2012, 14h20
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
15/10/2012, 14h41
tomlev

Citation:

Envoyé par sybe30

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é
25/10/2012, 14h27
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.